(12) NACH DEM VER> 
PATENTW 




UBER DIE INTERNATIONALE ZUSAMMEN 
fS (PCT) VEROFFENTLICHTE EMTERNATIO 



flu 

naLe AI 



AUF DEM GEBIET DES 
ANMELDUNG 



(19) Weltorganisation flir geistiges Eigentum 
Internationales Btiro 

(43) Internationales VerofFentlichungsdatum 
8. Januar 2004 (08.01.2004) 




ill 



PCT 



(10) Internationale Veroffentlichungsaummer 

WO 2004/003798 A2 



(51) Internationale Patentklassifikation 7 : G06F 17/60 

(21) Internationales Aktenzeichen: PCT/EP2003/006270 

(22) Internationales Anmeldedatum: 

13. Juni 2003 (13.06.2003) 



(25) Einreichungssprache: 

(26) VerofTentlichungssprache: 



Deutsch 
Deutsch 



(30) Angaben zur Prioritat: 

102 28 906.9 27. Juni 2002 (27.06.2002) DE 

102 36 384.6 8. August 2002 (08.08.2002) DE 

(71) Anmelder (flir alle Bestimmungsstaaten mil Ausnahme von 
US): DAIMLERCHRYSLER AG [DE/DE]; Epplestrasse 
225, 70567 Stuttgart (DE). 

(72) Erfinder; und 

(75) Erfinder/Anmelder (nur flir US): ZIMMERMANN, 



Johann, Ulrich [DE/DE]; Burlafingerstrasse 4, 89233 
Neu-Ulm (DE). 

(74) Anwalte: LINDNER- VOGT, Karin usw.; Daimler- 
Chrysler AG, Intellectual Property Management, IPM - C 
106, 70546 Stuttgart (DE). 

(81) Bestimmungsstaaten (national): JP, US. 

(84) Bestimmungsstaaten (regional): europaisches Patent (AT, 
BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, 
HU, IE, IT, LU, MC, NL, PT, RO, SE, SI, SK, TR). 

Veroflentlicht: 

— ohne internationalen Recherchenbericht und erneut zu ver- 
offentlichen nach Erhalt des Berichts 

Zur Erkldrung der Zweibuchstaben- Codes und der anderen Ab- 
kurzungen wird auf die Erkldrungen ("Guidance Notes on Co- 
des and Abbreviations") am Anfang jeder reguldren Ausgabe der 
PCT~Gazette verwiesen. 



(54) Title: INFORMATION GENERATION SYSTEM FOR PRODUCT FORMATION 

(54) Bezeichnung: INFORMATIONS ERZEUGUNGSSYSTEM FUR DIE PRODUKTENTSTEHUNG 




< 

00 

OS 15C 

m 

£5 (57) Abstract: The invention relates to a system (10) for the generation and storage of data objects (300.1, 300.2,..), each of which 
represent a component of a technical product or a step in a formation process for the product. According to the invention, the system 

^ (10) can generate types of relationships (600.1, 600.2, ...) between several data object types (500.1, 500.2, ...) and allocate said 
types to data object types (500.1, 500.2, ...) as well as automatically evaluated specifications for dependencies between data objects 

f*s| (300.1, 300.2, ...). A classification for data object types (500.1, 500.2, ...) in various phases of the formation process is preferably 
provided. The invention permits the coupling together of various applications (200.1, 200.2, ...) for separate given phases without 
the need to generate and maintain an intermediate model or direct interfaces between the applications. 

[Fortsetzung auf der nachsten SeiteJ 
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(57) Zusammenfassung: Die Erfindung betrifift ein System (10) zur Erzeugung und Speicherung von Datenobjekten (300.1, 
300-2,..), die jeweils einen Bestandteil eines technischen Produkts oder einen Schritt eines Entstehungsprozesses flir das 
Produkt reprasentieren. Erfindungsgemass vermag das System (10) Typen von Relationen (600.1, 600.2, ...) zwischen mehreren 
Datenobjekt-Typen (500.1, 500.2, ...) zu erzeugen und diesen Typen Datenobjekt-Typen (500.1, 500.2, ...) sowie automatisch 
auswertbare Vorschriften flir Abhangigkeiten zwischen Datenobjekten (300.1, 300.2, ...) zuzuordnen. Vorzugsweise ist eine 
Taxonomie flir Datenobjekt-Typen (500.1, 500.2, ...) verschiedener Phasen des Entstehungsprozesses vorgesehen. Die Erfindung 
ermoglicht es, verschiedene Anwendungen (200.1, 200.2, ...) fur jeweils bestimmte Phasen miteinander zu koppeln, ohne ein 
Zwischenmodell oder direkte Schnittstellen zwischen den Anwendungen erzeugen und pflegen zu mussen. 
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Inf ormationserzeugungs system fur die Produktentstehung 



Die Erfindurig betrifft ein System sowie ein Inf ormationsmo- 
dell zur Erzeugung von Inf ormationen uber Datenobjekte, die 
jeweils einen Bestandteil eines technischen Produkts oder ei 
nen Schritt eines Entstehungsprozesses fur das Produkt repra 
sentieren. 

Unter dem Begriff ProduktentstehungsprozeS wird eine Abfolge 
von Phasen und Aktivitaten verstanden, die zur Herstellung 
eines technischen Produkts notig sind. Zu diesen Phasen zah- 
len z. B . die Konstruktion und die Produkt i onspl anung . Die 
Aktivitaten einer Phase benotigen Zwischen- oder Endergebnis 
se von fruheren Phasen. Moglich ist es manchmal, mehrere Pha 
sen parallel auszufuhren. 

Die meisten oder gar alle Phasen des Produktentstehungspro- 
zesses z. B. fur eine Automobil-Baureihe werden heutzutage 
durch den Einsatz von Modellen und automatisch auswertbaren 
Inf ormationen auf Datenverarbeitungsanlagen unterstutzt. Ein 
Modell ist ein vereinf achtes und zwangslaufig liickenhaftes 
Abbild eines Ausschnitts der Realitat, hier des Produkts ode 
des Produkt entstehungsprozesses, auf einer Datenverarbei - 
tungsanlage. Das Modell enthalt die Eigenschaf ten und Abhan- 
gigkeiten der Realitat, die zur Losung einer bestimmten Auf- 
gabe einer Phase benotigt werden. Mit dem Begriff „Informati 
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on w wird der abstrakte Bedeutungsinhalt (die w Semantik tt ) ei- 
ner Aussage, Beschreibung, Anweisung, Nachricht oder Mittei- 
lung bezeichnet. Um Inf ormationen z. B. in einem Rechner zu 
reprasentieren und abzuspeichem werden Daten verwendet . Ein 
Inf ormationsmodell ist eine Vereinf achung der Realitat, durch 
die Inf ormationen und Fakten fur die Bearbeitung mindestens 
einer Aufgabe strukturiert werden. Ein Datenmodell be- 
schreibt, wie die gemaS eines Inf ormationsmodell s struktu- 
rierten Daten physikalisch gespeichert werden, z. B. in einer 
Datei oder einer Datenbank. 

Weil oft in jeder Phase spezifische Anf orderungen zu erfullen 
sind und diese Anf orderungen von Phase zu Phase differieren 
und weil fur die Erfullung dieser Anf orderungen z. T. spezi- 
fische Inf ormationen benotigt werden, wird in jeder Phase ei- 
ne spezifische Sicht auf das zu entwickelnde und zu fertigen- 
de technische Produkt benotigt. Gewunscht werden Ansatze, 
welche die Modelle und Inf ormationen der verschiedenen Phasen 
so verknupfen, daS die spezifischen Anf orderungen jeder Phase 
erfullt werden und dennoch die Modelle widerspruchsf rei zu- 
einander sind und moglichst keine Redundanzen, also mehrfache 
identische Inf ormationen, aufweisen. Anderungen an einem Mo- 
dell einer Phase werden idealerweise in Modellen anderer Pha- 
se nachgefuhrt. 

Moderne Werkzeuge fur den rechnerunterstiitzten Entwurf (com- 
puter-aided design, CAD) bieten die Moglichkeit, Konstrukti- 
ons-Gestaltungselemente (design features) oder allgemeiner 
Gestaltungselemente (features) , auch Funktionselemente ge- 
nannt, als Bestandteile von Produktmodellen zu definieren. 
Ein Konstruktions-Gestaltungselement reprasentiert eine Kom- 
ponente eines Bauteils und enthalt geometrische Festlegungen, 
z. B. Oberflachen, Kanten, geometrische Korper, Abrundungen. 
Bohrungen, Taschen, Nut en und Rippen an Zylinderkopf en von 
Automobil-Motoren sind Beispiele fur Konstruktions- 
Gestaltungselemente . Gestaltungselemente sind durch den Vor- 
schlag fur die Deutsche Norm DIN 32869-3 ^Technische Produkt- 
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dokumentation - Dreidimensionale CAD-Modelle - Teil 3: Funk- 
tionselernente" vom Februar 2002 bekannt . 

CAD-Werkzeuge, z. B. CATIA oder UniGraphics oder ProEngineer, 
bieten oft eine Bibliothek mit Typen von Gestal tungselementen 
sowie Funktionalitaten, mit denen ein Benutzer eigene Typen 
von Gestal tungselementen (user-defined feature types) erzeu- 
gen kann. Oft sind die Gestaltungselemente auf die spezifi- 
schen Anf orderungen und die Begriffswelt einer Phase zuge- 
schnitten. Sie sind die kleinsten Bausteine (building blocks) 
mit funktionaler Bedeutung, mit denen ein Benutzer ein Pro- 
dukt -Model 1 fur eine Phase aufbaut und damit eine spezifische 
Sicht auf das -Produkt realisiert. Gestaltungselemente repra- 
sentieren z. B. Bohrungen und Ausfrasungen, ihnen lassen sich 
Attribute mit einer Semantik fur die Konstruktion oder Ferti- 
gung zuordnen. Geometrische Grundelemente, z. B. Linien, 
Kreise und Quader, sind ebenfalls Bausteine, die in vielen 
Produkt-Modellen verwendet werden, aber keine funktionale Be- 
deutung besitzen. 

Aus T. N. Wong und C. B. Leung: „An object-oriented neutral 
feature model for feature mappings Internat. Journal of Pro- 
duction Research, Vol.38 (2000), pp. 3573 - 3601, sind Taxo- 
nomien (Verwandtschaf tshierarchien) unter Typen von Gestal - 
tungselementen bekannt. Eine Taxonomie bezieht sich bei Wong 
und Leung auf Gestaltungselemente einer Phase. Das Konzept 
von Typen und Exemplaren von Gestaltungselementen entspricht 
dem von Klassen und Objekten (classes and instances, classes 
and objects) der obj ekt -orient ierten Programmierung . In einer 
Taxonomie ist festgelegt, daJS ein Typ A ein Obertyp eines 
Typs B ist. Alle Eigenschaf ten des Typs A gelten auch fur den 
Typ B und damit fur alle Gestaltungselemente. 

Urn Modelle fur verschiedene Phasen des Produktentstehungspro- 
zesses zu verknupfen, wurden verschiedene Ansatze der Gestal- 
tungslemente -Transformation (feature mapping, feature conver- 
sion, feature transformation) vorgeschlagen. Die dahinterlie- 
gende Idee ist die: Gegeben ist eine Menge A von Gestaltungs- 
elementen fur eine erste Phase. Durch Anwendung einer Trans- 
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formation auf die Menge A wird eine Menge B von Gestaltungs- 
elementen fur eine zweite Phase erzeugt . Im allgemeinen Fall 
werden hierbei n Gestaltungselemente der Menge A auf m Ges- 
taltungselemente der Menge B abgebildet, also wird eine n:m- 
Abbildung ausgef uhrt . 

Aus F.-L. Krause, S. Kramer, E. Rieger: „ PDGL - a Language 
for Efficient Feature-Based Product Gestaltung", Annals of 
the CIRP, Vol. 40 No. 1 (1991), pp. 135 - 138, sowie aus F.- 
L. Krause, A. Ulbrich, F. H. Vosgerau: „Feature-Based Appro- 
ach for the Integration of Design and Process Planning Sys- 
tems", In: J. P. A. M. W. J. Turner (ed.), Proceedings of the 
23rd International Symposium on Automotive Technology & Auto- 
mation, Wien, Dec. 1990, pp. 140 - 147, ist eine Vorgehens- 
weise bekannt, durch die den Typen von Gestaltungselementen 
Wissen uber und Vorschriften fur die Transformation von Ges- 
taltungselementen (feature mapping knowledge) zugeordnet wer- 
den. In den Druckschrif ten wird eine formale Sprache namens 
„Part Design Graph Language w (PDGL) zur Representation der 
Vorschriften of f enbart . Die in PDGL formulierten Vorschriften 
werden z. B. von einem Interpreter der formalen Sprache abge- 
arbeitet. In J. J. Shah, D. Hsiao, J. Leonard: „A Systematic 
Approach for Design-Manufacturing Feature Mapping w , in P.R. 
Wilson, M.J. Wozny, M.J. Pratt (eds.): „Geometric Modeling 
for Product Realization", North-Holland Publ . , 1992, pp. 205 
- 221, werden automatisch ausfuhrbare Vorschriften direkt 
mittels einer Programmiersprache implementiert , und zwar als 
Teil der Verarbeitungs-Algorithmen eines Werkzeugs zum Pro- 
duktentwurf . Die Vorschriften legen fest, wie Typen benutzer- 
definierter Konstruktions-Gestaltungselemente (user defined 
design features) auf vorab definierte und in einer Bibliothek 
abgespeicherten Typen von Bearbeitungs-Gestaltungselemente 
(manufacturing features) abgebildet werden. Diese Abbildung 
wird mittels eines Rekonstruktions-Algorithmus , der die oben 
skizzierte Transformation realisiert, durchgefvihrt Der Algo- 
rithmus liefert einen „ Constructive Feature Tree". 
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In Y. S. Suh, M. J. Wozny: Interactive Feature Extraction for 
a Form Feature Mapping System", Rensselaer Polytechnic Insti- 
tute Troy, New York, 1998, und in T. N. Wong und C. B. Leung, 
a.a.O., werden Ansatze zur Transformation von Gestaltungsele- 
menten vorgestellt, die auf einem Zwischenmodell fur die Pro- 
dukt-Geometrie beruhen. Dieses Zwischenmodell enthalt anwen- 
dungsneutrale Typen und Exemplare von Zwischen- 
Gestaltungselementen. Die Transformation wird indirekt uber 
das Zwischenmodell durchgefuhrt . In W. F . Bronsvoort, 
A. Noort, J. van den Berg und G. F. M. Hoek: „ Product deve- 
lopment with multiple-view feature modelling", Proceed FEATS 
2001, und in K. J. De Kraker: „ Feature Mapping for Concurrent 
Engineering*', Promotionsschrif t , Delft University of Techno- 
logy, 1997, wird jeweils ein fur eine bestimmte Phase erzeug- 
tes und dort verwendetes Produktmodell als zentrales Zwi- 
schenmodell benutzt, namlich das Produktmodell fur die Phase 
Konstruktion (design feature model) . In beiden Druckschrif ten 
werden Gestaltungselemente in zwei Schritten automat isch aus 
der Bauteil-Geometrie identif iziert (feature recognition) , um 
aus den Konstruktions-Gestaltungselementen (design features) 
Gestaltungselemente fur andere Phasen zu erzeugen. Anderungen 
in anderen Phasen werden in beschranktem Umfang erkannt und 
fuhren automatisch zu entsprechenden Anderungen am Zwischen- 
modell. In Wong, a.a.O., werden aus Gestaltungselementen des 
neutralen Zwischenmodells anwendungsspezif ische Gestaltungs- 
elemente erzeugt . Hierfur werden regelbasierte Systeme ange- 
wendet, wie sie aus der „kiinstlichen Intelligenz w bekannt 
sind. 

Ein grundlegender Nachteil von Zwischenmodellen ist der, daS 
sich nur diejenigen Sachverhalte in einem phasenspezif ischen 
Modell beschreiben lassen, die sich auch im Zwischenmodell 
ausdriicken lassen. Daher muS das Zwischenmodell jede Informa- 
tion abspeichern, die in irgendeiner Phase benotigt wird. Da- 
her umfaSt das Zwischenmodell oft schwer zu handhabende Typen 
von „Allzweck-Gestaltungselementen n , eine Speicherung fiihrt 
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zu unerwunscht redundanter Datenhaltung und erfordert hohen 
Speicherplatzbedarf . 

Aus EP 785491 A2 sind ein Verfahren und eine Vorrichtung be- 
kannt, um Inf ormationen uber die Konstruktion und Informatio- 
nen uber die Produktion miteinander zu verknupfen und zu ver- 
walten. Zwischen verschiedenen Inf ormationen werden Relatio- 
nen hergestellt und verwendet , um von einer Gruppe von Inf or- 
mationen zu einer anderen Gruppe zu gelangen. Die Inf ormatio- 
nen z. B. uber Produkte, Bauteile und Fertigungsschritte 
(processes) werden durch Datensatze gespeichert, die Relatio- 
nen durch Verweise zwischen Datensatzen. Ein Datenbankschema 
wird erzeugt, durch das Datensatze in sinnvollen Beziehungen 
zueinander strukturiert und abgespeichert werden. Automatisch 
auswertbare Vorschriften werden in EP 785491 A2 nicht er- 
wahnt . 

Aus DE 19914454 Al sind ein rechnergestiitztes System und ein 
Verfahren zum Aufbau einer Datenbank bekannt . Die aufzubauen- 
de Datenbank umfa&t zwei Grundtabellen . In jeder dieser 
Grundtabellen werden Elemente einer Grundklasse, also z. B. 
Datenobjekte eines Datenobjekt-Typs, abgespeichert. In einer 
Beziehungstabelle lassen sich Beziehungen zwischen den Ele- 
menten der beiden Grundtabellen abspeichern. Die Datenbank 
kann mehrere Beziehungstabellen fur die beiden Grundtabellen 
umfassen. Jeder Beziehung einer Beziehungstabelle laSt sich 
eine Beziehungskategorie zuordnen. Die Beziehungskategorien 
sind in einer Kategorietabelle abgespeichert. 

In einem Ausf uhrungsbei spiel werden u. a. die Grundklassen 
" w W6rter\ „Personen", „Projekte" und „Sachen" definiert. Ein 
Wort kann Nachname einer Person sein. Eine Person kann Erfin- 
der einer durch ein Wort bezeichneten Sache sein. In einer 
Beziehungstabelle sind die beiden Beziehungen „Wort - Person" 
und „ Person - Wort" abgespeichert. In der Kategorientabelle 
sind als Beziehungskategorien „Nachname" und w Erfinder tt abge- 
speichert und den Beziehungen „Wort - Person" bzw. „ Person - 
Wort" zugeordnet. In einer Relationstabelle sind alle mogli- 
chen Beziehungen zwischen den beiden Grundtabellen abgespei- 



WO 2004/003798 PCT/EP2003/006270 



chert und mit den Eintragen in der Kategorietabelle verbun- 
den. Beispielsweise sind der Beziehungskategorie „Name w in 
der Kategorietabelle durch entsprechende Eintrage in der Re- 
lationstabelle die Beziehungen „ Person - Wort", „Sache - 
Wort\ „ Pro j ekt - Wort" und „Objekt - Wort w zugeordnet. 

In DE 19816658 Al wird ein relationales Speicher- und Daten- 
verarbeitungssystem offenbart. Das System umfaSt einen Spei- 
cher nach Art eines semantischen Netzes mit Datenobj ekten und 
Relationen zwischen diesen Datenobj ekten, Eine derartige Re- 
lation laSt sich mit einem Datenobj ekt mit Hilfe einer Rela- 
tion-Relation verknupfen. Zwei Relationen lassen sich mitein- 
ander mittels einer Relation-Relation verknupfen. 

Beispielsweise sind zwei Datenobj ekte CI, C2 fur zwei Compu- 
tersysteme einer Rakete jeweils mittels einer Relation „ver- 
wendet" mit einem Datenobj ekt L fur ein Lagekont roll system 
verbunden. Die Relation „verwendet" zwischen CI und L ist li- 
ber eine Relation-Relation „wahrend u mit einem Datenobj ekt 
fur den Betriebszustand „Normal u verknupft. Die Relation 
„verwendet" zwischen C2 und L ist xiber eine Relation-Relation 
„wahrend" mit einem Datenobj ekt fur den Betriebszustand „Not- 
fall* verknupft. 

Der Erfindung liegt die Aufgabe zugrunde, ein System nach dem 
Oberbegriff des Anspruchs 1 und ein Inf ormationsmodell nach 
dem Oberbegriff des Anspruchs 13 zu schaffen, die kein Zwi- 
schenmodell erfordern und durch die sich die automat isch aus- 
wertbaren Vorschriften fur Abhangigkeiten zwischen Datenob- 
j ekten effizient und ohne Redundanz aufstellen, erweitern, 
andern, speichern und loschen lassen. 

Die Aufgabe wird durch ein System nach Anspruch 1 und durch 
ein Inf ormationsmodell nach Anspruch 13 geldst. Vorteilhafte 
Ausgestaltungen sind in den Unteranspruchen angegeben. 

Erf indungsgemaS werden neben den Datenobj ekten, die Bestand- 
teile des Produkts oder Prozesses reprasentieren, weitere Da- 
tenobj ekte vorgesehen, namlich Relationen zwischen Datenob- 
j ekten und Typen derartiger Relationen. Dadurch, daS die Ab- 
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hangigkeiten zwischen Datenob j ekten als spezielle, ebenfalls 
typisierbare Datenobjekte behandelt werden, wird eine modula- 
re Datenhaltung erreicht und unerwunschte Redundanz in der 
Datenhaltung reduziert . Insbesondere die modulare Datenhal- 
tung fuhrt dazu, dafi sich die Vorschriften leicht aufstellen, 
erweitern, andern und loschen lassen. 

Datenobjekte fur verschiedene Phasen oder von verschiedenen 
Anwendungen werden durch derartige Relationen verknupft. Ins- 
besondere verbinden diese Relationen solche Datenobjekte, die 
dasselbe Bestandteil des Produkts oder Prozesses fur ver- 
schiedene Phasen represent ieren. Dank der Relationen laSt 
sich automatisch und effizient ermitteln, welche Datenobjekte 
sich auf dasselbe Bestandteil beziehen und welche weiteren 
Datenobjekte nach Anderung eines ersten Datenob jekts veran- 
dert werden mtissen, damit alle Datenobjekte fur ein Bestand- 
teil zueinander konsistent bleiben. Damit reduziert die Er- 
findung die Anzahl und die Schwere von Fehlern im Produk- 
tentstehungsprozefi, insbesondere die solcher Fehler, die auf 
Widerspruchen zwischen den verschiedenen Produkt- oder Pro- 
zefimodellen beruhen. Anderungen an einzelnen Model len werden 
vereinfacht, weil die automatisch ausfuhrbaren Vorschriften, 
welche die Konsequenzen der Anderungen ermitteln und/oder au- 
tomatisch ausfiihren, effizient und ohne Redundanz aufstell- 
bar, erweiterbar, anderbar, speicherbar und loschbar sind. 

Die Relationen sind in Typen klassif izierbar . Dadurch brau- 
chen Inf ormationen, die fur n ahnliche Relationen Rel_l, ... 
, Rel_n zwischen Datenobj ekten gultig sind, nicht mehrfach 
formuliert und abgespeichert zu werden. Beispiele fur derar- 
tige Inf ormationen sind automatisch auswertbare Vorschriften, 
Attribute, zulassige Wertebereiche , Vorzugswerte oder Stan- 
dardwerte (default values) sowie Abhangigkeiten (constraints) 
und Berechnungsvorschrif ten zwischen Attributen von durch ei- 
ne Relation verbundenen Dat enobjekt- Typen . Vielmehr wird ein 
Typ von Relationen erzeugt, und festgelegt wird, daS Rel_l, 
... , Rel_n alle von diesem Typ sind. Die Inf ormationen wer- 
den dem Typ zugeordnet und brauchen nur einmal erzeugt und 
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abgespeichert zu werden. Sie sind damit fur Rel_l, ... , 
Rel_n gultig. 

Nicht jedes Datenobjekt und jede Relation ist notwendigerwei - 
se einem Datenobjekt -Typ bzw. Relations -Typ zugeordnet. Die- 
jenigen Datenobjekte und Relationen, die einem Typ zugeordnet 
sind, werden als „typisiert" bezeichnet. 

Die Einfuhrung von Relations-Typen erlaubt einen einfachen 
und einheitlichen Zugriff auf alle Relationen eines Relati- 
ons-Typs. Beispielsweise kann eine Anwendung des Produktent- 
stehungsprozesses alien Relationen ein neues Attribut zuord- 
nen oder Auswertungen uber die jenigen Attributwerte machen, 
die die Relationen eines Typs annehmen. Die Anwendung braucht 
nicht den jeweiligen Namen der Relationen oder eine Kennung 
(identifier) oder einen Zugriffspfad auf die Relationen des 
Typs zu kennen, urn den Zugriff durchzuf iihren. Weiterhin er- 
leichtert die Einfuhrung von Relations-Typen die Filterung 
bestimmter Relationen erheblich, weil z. B. lediglich be- 
st immte Relations-Typen vorgegeben zu werden brauchen und al- 
le Relationen dieser vorgegebenen Relations-Typen herausge- 
filtert werden. Diese Filterung erleichtert das Wiederauf fin- 
den von Inf ormationen, was zu geringeren Rechenzeiten fuhrt 
und die Arbeit von Fachexperten erleichtert. 

Die automatisch auswertbaren Vorschriften werden diesen Rela- 
tions-Typen zugeordnet und nicht z. B. einzelnen Relationen 
oder gar Typen von Konstruktions-Gestaltungselementen (design 
features) . Dadurch bleiben Datenobjekt -Typen frei. von Verwei- 
sen auf andere Datenobjekt -Typen, was unvermeidlich ware, 
wenn die automatisch auswertbaren Vorschriften Datenobj ekt- 
Typen zugeordnet werden wurden. Dieses Merkmal ist insbeson- 
dere dann von Vorteil, wenn ein anderer Datenobj ekt-Typ, auf 
den ein erster Datenobjekt -Typ verweist, geloscht wird. Wenn 
der erste Datenobjekt -Typ einen Verweis auf den anderen Da- 
tenobj ekt-Typ hatte, miiSte sichergestellt werden, daS dieser 
Verweis beim Loschen des anderen Datenobj ekt- Typs geloscht 
wird. Durch die Erfindung werden Datenobjekte getrennt von 
ihren wechselseitigen Beziehungen erzeugt und abgespeichert. 
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Das erf indungsgemaSe System benotigt kein Zwischenmodell , das 
fur mehrere Phasen des Produktentstehungsprozesses gultig 
ist . Dadurch vermeidet das System die oben beschriebenen 
Nachteile . 

Die groSe Komplexitat aufgrund der vielen verschiedenen Da- 
tenobjekte fur die Phasen wird beherrschbar gemacht . 

Vorzugsweise werden die automatisch auswertbaren Vorschriften 
so formuliert, da£ sie nicht von einer bestimmten Anwendung 
des Produktentstehungsprozesses abhangen, sondern anwendungs- 
neutral sind. Dadurch laSt sich eine zusatzliche Anwendung 
erganzen oder eine alte durch eine neue ersetzen, ohne die 
Datenhaltung anderer Anwendungen andern zu mussen. Die Vor- 
schriften reprasentieren Informationen daruber, welche Be- 
rechnungen, Auswertungen und Generierungen durchzuf uhren 
sind. Informationen, wie die Vorschriften im einzelnen auszu- 
f uhren sind, werden der jeweiligen ausfuhrenden Anwendung zu- 
geordnet . 

Weil automatisch auswertbare Vorschriften den Relations-Typen 
zugeordnet werden, lassen die Vorschriften sich andern, ohne 
Typen von Datenob j ekten verandern zu mussen. Die Vorschriften 
werden direkt den Typen derjenigen Datenobjekte zugeordnet, 
auf die sie sich beziehen, namlich Typen von Relationen zwi- 
schen Datenob j ekten. Vermieden wird die Notwendigkeit , eine 
komplexe unstrukturierte Wissensbasis fur viele verschiedene 
Vorschriften auf zustellen. Eine solche Wissensbasis ist nur 
schwer zu warten. Die Gefahr ist groS, daS sich unentdeckte 
Fehler in eine solche Wissensbasis einschleichen und zu feh- 
lerhaften Produktentwurf en oder gar fehlerhaften Produkten 
f iihren . 

Ein weiterer Vorzug der Erfindung ist der, daS sie bereits 
dann produktive Ergebnisse liefern kann, wenn noch nicht alle 
Datenob jekt -Typen durch Relations-Typen miteinander verbunden 
sind. Vielmehr kann das erf indungsgemaSe System auch mit un- 
vollstandigen Informationen arbeiten, z. B. mit Relations- 
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Typen fur nur einige der Abhangigkeiten zwischen Datenobjekt- 
Typen. Spatere Erganzungen machen es nicht erf orderlich, fru- 
here Festlegungen nachtraglich zu iiberarbeiten. Dieser Aspekt 
ist insbesondere dann wichtig, wenn der Produktentste- 
hungsprozeS in einem Unternehmen bereits etabliert ist, spe- 
zifische Anwendungen fur einzelne Phasen im produktiven Ein- 
satz sind und daher das erf indungsgemaSe System bei seiner 
Einfuhrung schrittweise mit den bestehenden produktiv genutz- 
ten Anwendungen gekoppelt wird, weil es unmoglich ist, es im 
laufenden Betrieb schlagartig mit alien diesen Anwendungen zu 
kombinieren oder gar den laufenden Betrieb fur die Einfuhrung 
zu unterbrechen. Unterschiedliche Grade der Kopplung ver- 
schiedener Anwendungen sind mittels des erf indungsgemaSen 
Systems realisierbar . Das erf indungsgemaSe System kann zu- 
nachst prototypisch fur einzelne Phasen und Anwendungen ein- 
gesetzt werden und schrittweise mit weiteren Anwendungen ge- 
koppelt werden. Vor allem diese Skalierbarkeit ermoglicht es, 
das erf indungsgemaSe System evolutionar in einen bestehenden 
ProduktentstehungsprozeS einzufuhren. Der oben genannte As- 
pekt ermoglicht es daruber hinaus, die Erfindung im Verlaufe 
eines Produktentstehungsprozesses anzupassen, anstelle wah- 
rend des gesamten Produktentstehungsprozesses mit einem star- 
ren Datenhaltungsschema auskommen zu mussen. 

Die Einfuhrung von Relations-Typ-Kategorien unter Relations- 
Typen ist ein weiteres Merkmal, durch welches doppelte und 
unerwunscht redundante Datenhaltung vermieden wird. Informa- 
tionen, die fur m Relations -Typen T_l, ... , T__m gultig sind, 
werden einer Relations-Typ-Kategorie K zugeordnet . Die Infor- 
mationen werden einmal formuliert und abgespeichert . Bei der 
Erzeugung der m Relations-Typen T_l, ... , T_m wird vorgege- 
ben, daS diese m Typen von der Relations-Typ-Kategorie K 
sind. Dadurch sind die Festlegungen fur K fur die m Relati- 
ons-Typen gultig. Moglich ist auch, einen Relations-Typ T_i 
nachtraglich einer Relations-Typ-Kategorie zuzuordnen. 

Insbesondere laSt sich fiir eine Relations-Typ-Kategorie fest- 
legen, welche Attribute und Methoden die Relations-Typen der 
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Kategorie haben mussen. Weitere Beispiele fur Inf ormationen, 
die einer Relat ions -Typ- Kategorie zugeordnet sind, sind die 
Festlegungen, daS jeder Relations -Typ der Kategorie einen Na- 
men und eine automatisch auswertbare Vorschrift besitzen mu£. 
Verarbeitungs-Algorithmen lassen sich ebenfalls einer Katego- 
rie zuordnen. Fur eine Relations -Typ-Kategorie kann eine Vor- 
schrift festgelegt sein, welche die Zuordnung von Datenob- 
jekt-Typen an Relations -Typen der Kategorie einschrankt oder 
uberpruft. Diese Vorschrift nimmt z. B. Bezug auf Datenob- 
jekt -Typen. Moglich ist auch, Kategorien von Datenobj ekten 
einzufuhren und in einer Vorschrift # die einer Relat ions -Typ- 
Kategorie zugeordnet ist, Bezug auf Datenobj ekt -Kategorien zu 
nehmen . 

Ein weiterer Vorteil der Verwendung von Relat ions -Typ - 
Kategorien tritt auf, wenn Inf ormationen, die fur mehrere Re- 
lations-Typen der gleichen Relations -Typ-Kategorie gultig 
sind, nachtraglich geandert werden mussen, z. B. aufgrund ei- 
nes neuen Konstruktionsstandes, neuer Anf orderungen an das zu 
entwerfende und zu fertigende Produkt oder weil Fehler im al- 
ten Entwurf oder Arbeitsplan offenbar wurden. Weil die Inf or- 
mationen nur einmal abgespeichert sind, namlich als Teil der 
Inf ormationen uber eine Relations -Typ-Kategorie, brauchen sie 
nur einmal geandert zu werden. Waren sie hingegen mehrfach 
und redundant abgespeichert, miiSten mehrere Anderungsvorgange 
durchgefuhrt werden. Die Gefahr ist grofi, daS ein erforderli- 
cher Ande rungs vorgang gar nicht oder nur unvollstandig oder 
fehlerhaft ausgefuhrt wird und dadurch Fehler in das Produkt - 
modell geraten. 

Bestimmte Relations-Typen lassen sich dadurch automatisch 
auswahlen, daS mindestens eine bestimmte Relations -Typ- 
Kategorie vorgegeben wird, wodurch alle Relations-Typen der 
vorgegebenen Kategorie ausgewahlt sind. Dadurch ist eine in- 
telligente Filterung von und eine Fokussierung auf bestimmte 
Relations-Typen moglich. 

Die Taxonomie unter Relat ions-Typ-Kategorien ordnet die u. U. 
umfangreiche Menge von Relations-Typen. Eine Anwendung kann 
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automatisch syntaktische Regeln und eine Semantik fur einen 
Relations-Typ ermitteln, indem sie die zugeordnete Relations- 
Typ-Kategorie und ihre Position in der Taxonomie ermittelt 
und die Inf ormationen uber diese Relations-Typ-Kategorie aus- 
wertet. Die Gefahr wird reduziert, daS verschiedene Relati- 
ons -Typen fur denselben Sachverhalt eingefuhrt werden. Da- 
durch werden unerwunschte Redundanz und Uberschneidungen ver- 



Vorzugsweise wird eine einheitliche Taxonomie unter alien Ty- 
pen von Datenobjekten aufgestellt. Diese Taxonomie umfaSt 
mehrere Phasen des Produktentstehungsprozesses sowie Datenob- 
jekt-Typen fur unterschiedliche Abstraktionsebenen des Pro- 
dukts, also z. B. Zusatnmenbauten, Bauteile, Konstruktions- 
Gestaltungselemente und Fertigungs-Gestaltungselemente in ei- 
ner einzigen Taxonomie, Insbesondere ist die Taxonomie nicht 
auf Typen von Gestaltungselementen beschrankt . Dadurch lassen 
sich verschiedene Phasen und Abstraktionsebenen einheitlich 
und mit gleicher Notation behandeln. 

Bevorzugt werden die Taxonomie unter Relations -Typ-Kategorien 
und die Taxonomie unter Datenobj ekt- Typen nicht fur jeden 
ProduktentstehungsprozeS erneut erzeugt . Vielmehr umfaSt das 
erf indungsgemaSe System zwei anwendungsubergreif ende und vor- 
ab definierte und erweiterbare Standard-Bibliotheken, namlich 
eine mit Datenobj ekt -Typen und eine weitere mit Kategorien 
von Relations-Typen zwischen diesen Datenobj ekt -Typen. Diese 
beiden Standard- Bibliotheken sind z. B. fur jede Baureihe 
eines Automobilherstellers, die gemaS einem einmal definier- 
ten ProduktentstehungsprozeS entworfen und hergestellt wird, 
gultig. Sie lassen sich als Ausgangspunkt fur einen bestimm- 
ten ProduktentstehungsprozeS, beispielsweise eine bestimmte 
neue Baureihe eines Automobilherstellers, verwenden und er- 
weitern, z. B. fur den ProduktentstehungsprozeS einer be- 
stimmten Baureihe oder eine bestimmte Anwendung . Vorzugsweise 
haben die Bibliotheken datentechnisch die Form von einbindba- 
ren Software -Bibliotheken (libraries) oder von Datensatzen in 
einer Datenbank. Moglich ist auch, nur die Standard- 
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Bibliothek fur Datenobjekt-Typen oder nur das fur Relations - 
Typen vorzusehen . 

Spe z i f i s che Da t enob j ekt - Typen und Re 1 at ions - Typ - Ka t egor ien 
werden als Unter typen von Datenobjekt-Typen bzw. Relations- 
Typ -Kat egor ien der Standard-Bibliotheken erzeugt . Attribute 
und sonstige Informationen, die einem Datenobjekt-Typ bzw. 
eine Relations-Typ-Kategorie der jeweiligen Standard - 
Bibliothek zugeordnet sind, sind durch Vererbung entlang der 
Taxonomie der Datenobjekt-Typen bzw. der Relations-Typ- 
Kategorien auch fur alle Untertypen gultig - es sei denn, fur 
den Datenobjekt-Typ bzw. die Relations -Typ- Kategorie festge- 
legt. Festlegungen fur einen spezif ischeren Datenobjekt-Typ 
uberschreiben geerbte Festlegungen fur einen abstrakteren Da- 
tenobjekt-Typen (overloading) . Spezif ische Typen und Katego- 
rien besitzen dadurch, daS sie als Untertypen bzw. Unterkate- 
gorien von Typen bzw. Kategorien einer anwendungsubergrei fen- 
den Standard-Bibliothek erzeugt wurde, bereits durch die Er- 
zeugung eine grobe Semantik und konnen von Anwendungen ausge- 
wertet werden. Beispielsweise kann eine Vorschrift, die auf 
einen Typ oder eine Relation einer Standard-Bibliothek Bezug 
nimmt, auch auf den spezif ischen Untertyp bzw. auf die Unter- 
kategorie angewendet werden. Denn der Untertyp bzw. die Un- 
terkategorie besitzt durch Vererbung mindestens alle diejeni- 
gen Vorschrif ten, Methoden, Attribute etc., die dem Typ bzw. 
der Kategorie aus dem Standard-Bibliothek zugeordnet sind. 

Die Taxonomie unter Datenobjekt-Typen erleichtert die Zuord- 
nung von Datenobjekt-Typen an Relations-Typen. Einem Relati- 
ons-Typ konnen z. B. zwei abstrakte Datenobjekt-Typen zuge- 
ordnet sein, das sind zwei Datenobjekt-Typen, die Wurzeln von 
Asten der baumartigen Taxonomie sind, also mehrere Untertypen 
haben. Durch diese Zuordnung ist festgelegt, daS eine Relati- 
on des Relations-Typs zwei Datenobjekte von zwei Datenobjekt- 
Typen dieser beiden Aste verbinden darf , aber keine Datenob- 
jekte anderer Datenobjekt-Typen. Die Prufung wird z. B. auto- 
matisch nach der Erzeugung einer Relation durchgef uhrt . Die 
Taxonomie unter Datenobjekt-Typen kann Mehrfach- Vererbung 
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vorsehen, d. h. ein Datenobj ekt-Typ kann mehrere andere Da- 
tenobj ekt-Typen als Obertypen haben und von diesen verschie- 
dene Vorschrif ten, Methoden oder Attribute erben. Die Taxono- 
mie bildet dann keinen Baum mehr, sondern einen gerichteten 
azyklischen Graphen. 

Bevorzugt wird - zusatzlich zur Verknupfung von Datenobj ekten 
durch Relationen - eine automat ische Erkennung von Gestal- 
tungselementen (feature recognition, feature identification) 
durchgef uhrt . Hierbei werden bestimmte noch nicht typisierte 
Bestandteile eines Produkt- oder Prozefimodells dadurch typi- 
siert, daS sie vorab definierten Datenobj ekt-Typen zugeordnet 
werden. Vorzugsweise wird ermoglicht, dafi ein Bestandteil 
nicht nur einem Blatt der Taxonomie unter Datenobj ekt-Typen 
zugeordnet werden kann, sondern auch einem abstrakten Daten- 
objekt-Typ. Anschliefiend werden diese Datenobjekte durch Re- 
lationen mit weiteren Datenobj ekten fur andere Phasen des 
Produkt en t s t ehung sp r o z e s s e s ve rbunden . 

Vorzugsweise werden Datenobj ekt-Typen und damit Datenobjekte 
bestimmten Phasen des Produktentstehungsprozesses zugeordnet. 
Ein Datenobj ekt-Typ kann mehreren Phasen zugeordnet sein. Die 
Phasen werden z. B. ebenfalls als Datenobj ekt-Typen model - 
liert, die durch Relations-Typen mit anderen Datenobj ekt- 
Typen verbunden sind. 

Das erf indungsgema&e System umfaSt vorzugsweise (Anspruch 8) 
eine Einrichtung zur Zuordnung eines Datenobj ekt-Typs zu min- 
destens einer von mindestens zwei verschiedenen Phasen des 
Entstehungsprozesses und eine Einrichtung zur Erzeugung einer 
einzigen Taxonomie fur Datenobj ekt-Typen, ...), die einer 
ersten Phase zugeordnet sind, und fur Datenobj ekt-Typen 
(500.1, 500.2, ...), die einer zweiten Phase zugeordnet sind. 
Die Taxonomie kann Datenobj ekt-Typen fur beliebig viele Pha- 
sen umfassen. Diese Ausgestaltung wird vorzugsweise mit einem 
System mit den Merkmalen des Anspruchs 1 kombiniert . Es ist 
aber auch moglich, ein System zur Erzeugung von Inf ormationen 
uber Datenobjekte vorzusehen, wobei das System 
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eine Einrichtung zur Erzeugung von Typen von Datenobjek- 
ten, 

eine Einrichtung zur Zuordnung eines Datenobjekt-Typs zu 
einer Phase 

und eine Einrichtung zur Erzeugung einer einzigen Taxono- 
mie fur Datenobj ekt -Typen 

umf a£t . 

Im folgenden wird ein Ausf uhrungsbei spiel des erf indungsgema- 
Sen Systems und Inf ormationsmodells anhand der beiliegenden 
Zeichnung naher beschrieben. Dabei zeigen: 

Fig. 1. das Zusammenspiel des erf indungsgemaSen Systems mit 
mehreren Anwendungen; 

Fig. 2. eine Architektur mit dem erf indungsgemaSen System 
und mehreren Anwendungen; 

Fig. 3. einen Ausschnitt aus einer Taxonomie unter Datenob- 
j ekt- Typen. 

Fig. 1 veranschaulicht fur diese Ausf uhrungs form das Zusam- 
menspiel des erf indungsgemaSen Systems mit vier Anwendungen 
2 00.1, 200.2, 2 00.3 und 200.4. Das erf indungsgemafie System 10 
umfaSt das zentrale Diensteprogramm 98 sowie die zentrale Da- 
tenbank 100 mit Relations-Typ-Kategorien, Datenobjekt- und 
Relations -Typen sowie Relationen 400.1, 400.2, 400.3, 400.4. 
Relations-Typ-Kategorien einerseits, Relations -Typen 600 und 
Datenobj ekt -Typen 500 andererseits und Relationen 400 als 
Drittes bilden logisch drei unterschiedliche Abstraktionsebe- 
nen, werden aber vorzugsweise physikalisch in derselben zent- 
ralen Datenbank 100 gespeichert . Inf ormationsweiterleitungs- 
Schnittstellen 250 verbinden das zentrale Diensteprogramm 98 
mit vier Anwendungen 200.1, 200.2, 200.3 und 200.4. Die. bei- 
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den Anwendungen 200.2 und 200.4 verwalten je eine lokale Da- 
tenhaltung 110.1 und 110.2, die mit Daten aus der zentralen 
Datenbank 100 gefullt wird. Alle vier Anwendungen verwalten 
spezifische Pr odukt model le 150.1, 150.2, 150.3 und 150.4 mit 
Datenobjekten 300.1, 300.2, 300.3, 300.4 und 300.5. Zwischen 
drei Datenobjekten 300.1, 3 00.2 und 300.5 in den Produktmo- 
dellen 150.1 und 150.3 besteht in diesem Beispiel eine Rela- 
tion 400.1, zwischen 300.2 und 300.4 in den Produktmodellen 
150.2 und 150.4 eine Relation 400.2. Die Relation 400.1 ver- 
bindet also drei Datenmodelle miteinander, von denen zwei 
derselben Anwendung und das dritte einer anderen Anwendung 
angehoren. Diese Relationen werden in der zentralen Datenbank 
100 abgespeichert und verwaltet. Eine derartige Architektur 
wird im folgenden eingehender beschreiben. 

Das erf indungsgemaSe System 10 wird mit Hilfe einer zentralen 
Datenverarbeitungsanlage realisiert, die vorzugsweise mit 
mehreren anderen Datenverarbeitungseinrichtungen verbunden 
ist. Das System 10 umfaSt ein zentrales Diensteprogramm (ap- 
plication server) 98 sowie eine zentrale Datenbank 100. Vor- 
zugsweise fungiert das erf indungsgemafie System 10 als zentra- 
les Datenhaltungssystem fur die Anwendungen 2 00 und damit fur 
mehrere Phasen des Produktentstehungsprozesses . Dadurch wird 
eine Anwendung 200 fur eine Phase mit Daten und Inf ormationen 
aus anderen Phasen versorgt, und die einzelnen Anwendungen 
werden besser miteinander integriert. Diese Versorgung mit 
Daten und Inf ormationen vermeidet Fehler, die z. B. aufgrund 
von Medienbriichen entstehen, spart Zeit ein und erleichtert 
Anderungen, weil die Auswirkungen einer Anderung in einer 
Phase auf andere Phasen oder auf andere Anwendungen 200 er- 
mittelt werden. 

Die Anwendungen 2 00 losen in der Regel spezifische Aufgaben 
fur bestimmte Phasen des Produktentstehungsprozesses. Zu die- 
sen Phasen zahlen z. B. Auslegung (concept design), Konstruk- 
tion (detailed design) , Berechnungen, Konstruktion der zur 
Produktf ertigung benotigten Werkzeuge, Prototypenbau und Er- 
probung, Arbeitsplanung fur die Serienproduktion, Ressourcen- 
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planung, Arbeit splanung fur die Serienproduktion einschlieS- 
lich Betriebsmittelplanung, Serienproduktion, Qualitatskon- 
trolle, Auswertung von Erfahrungen im Serieneinsatz . Beispie- 
le fiir die Anwendungen 200 auf den Datenverarbeitungseinrich- 
tungen sind Sof tware-Systeme zur Konstruktion (computer-aided 
design, CAD) , zur Produktdaten-Verwaltung (product data mana- 
gement, product engineering management), zur Produkt simulati- 
on mittels Berechnungsmodellen z. B. fur das Verhalten des 
Produkts bei mechanischen Belastungen, zur Fertigungsplanung, 
zur Ressourcenplanung (enterprise resource management) , zur 
Programmierung von Bearbeitungsmaschinen, zur Durchfuhrung 
und Auswertung von Messungen zur Qualitatssicherung und zum 
Abarbeiten eines Arbeitsablauf s (workflow management) . 

Jede dieser Anwendungen 200 verwendet eine spezifische Sicht 
auf das Produkt und benotigt bestimmte Datenobjekte 300. 
Grunde fur die unterschiedlichen Sichten sind die, dafi jede 
Anwendung 200 spezifische Aufgaben zu erfullen hat und dafur 
spezifische Daten, Inf ormationen und Wissen benotigt und be- 
stimmte Arbeitszustande beim Problemlosen erf ordert . Ein Da- 
tenobjekt 3 00 gehort zu mindestens einem bestimmten Model 1 
150, das seinerseits zu einer bestimmten Sicht auf das Pro- 
dukt oder den ProzeS gehort und von mindestens einer Anwen- 
dung 2 00 fiir eine Phase des Produktentstehungsprozesses er- 
zeugt und bearbeitet wird. Moglich ist, daS dasselbe Modell 
von verschiedenen Anwendungen 2 00 bearbeitet wird. 

Diese Anwendungen sowie die zentrale Datenbank 100 sind uber 
Inf ormationsweiterleitungs-Schnittstellen 250 mit dem zentra- 
len Diensteprogramm verbunden. Vorzugsweise sind keine 
Schnittstellen vorgesehen, die zwei Anwendungen 200. a, 200. b 
direkt miteinander oder eine Anwendung 200 mit der zentralen 
Datenbank 100 des Systems 10 verbinden. Dadurch wird der Ent- 
wicklungs- und Pf legeauf wand reduziert: Bei n Anwendungen 
200.1, ... , 200. n sind nur n Schnittstellen zwischen den An- 
wendungen und dem zentralen Diensteprogramm 98 erf orderlich . 
Falls direkte Schnittstellen zwischen den n Anwendungen 
200.1, ... , 200. n erforderlich waren, sind im Extremfall 
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insgesamt n*(n-l)/2 Schnittstellen zu entwickeln und zu pfle- 
gen. Fur n=10 sind dank der Erfindung nur 10 anstelle im Ex- 
tremfall 45 Schnittstellen zu entwickeln. Durch die zentrale 
Datenhaltung ist dariiber hinaus eine Konversion zwischen an- 
wendungsspezif ischen Produkt- oder ProzeSmodellen 15 0 und den 
jeweils verwendeten Informations- und/oder Datenmodellen 
nicht erf orderlich. 

Fig. 2 zeigt eine beispielhaf te Architektur mit dem erfin- 
dungsgemaEen System 10 und vier Anwendungen 200.1, 200.2, 

200.3 und 200.4. Die vier Anwendungen sind uber vier Informa- 
tionsweiterleitungs-Schnittstellen 250.1, 250.2, 250.3 und 

250.4 mit dem zentralen Diensteprogramm 98 verbunden. Direkte 
Schnittstellen zwischen zwei Anwendungen 200.1 , 200. b oder 
eine Schnittstelle zwischen einer lokalen Datenhaltung 100.x 
und der zentralen Datenbank 100 sind nicht erf orderlich. Wei- 
terhin umfafit das System 10 eine Benutzeroberf lache 50. 

Die zentrale Datenhaltung wird vorzugsweise ausschliefilich 
vom zentralen Diensteprogramm 98 beschrieben und ausgelesen. 
Nur das zentrale Diensteprogramm 98, nicht aber die Anwendun- 
gen 200.1, 200.2, 200.3 und 200.4, haben Schreib- und Lese- 
zugriff auf die zentrale Datenbank 100. In der zentralen Da- 
tenbank 100 werden folgende Inf ormationen dauerhaft verwaltet 
und uber das zentrale Diensteprogramm 98 und den Informati- 
onsweiterleitungs -Schnittstellen 250 den Anwendungen verfug- 
bar gemacht : 

- die Relations-Typ-Kategorien und die Taxonomie unter die- 



- die Datenobjekt-Typen 500 und die Taxonomie unter diesen 

die Relations-Typen einschlieSlich der Taxonomie unter 
diesen und den automatisch auswertbaren Vorschriften 

und die Relationen 4 00 und die Verweise von diesen auf die 
jeweiligen Relations-Typen. 

Eine Anwendung 200.1 „kennt" also nach einem Lesezugriff Re- 
lationen, z. B. eine Relation 400.1 zwischen einem Datenob- 
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jekt 300.1 eines von der Anwendung 200.1 erzeugen Modells 
150.1 und einem weiteren Datenobjekt 300.3 eines Modells 
150 . 3 , das von einer anderen Anwendung 2 00.3 erzeugt wurde . 
In den Modellen 150 oder lokalen Datenspeichern 110 werden 
hingegen vorzugsweise keine Inf ormationen uber die anderen 
Modelle abgespeichert , damit nicht ein Modell einer Anwendung 
direkte Verweise auf ein Modell einer anderen Anwendung be- 
sitzt . 

Datenobjekte 300 und Anwendungen 2 00 zum Erzeugen, Bearbeiten 
und Auswerten von Datenobj ekten, insbesondere von Konstrukti- 
ons- und Fertigungs-Gestaltungselemente, sind oft auf die 
spezifischen Anf orderungen der Phase zugeschnitten. Sie rep- 
rasentieren die fur die jeweilige Phase relevanten Bestand- 
teile des Produkts oder Prozesses . Die Datenobjekte 300 und 
Relationen 400 bilden die Bausteine (building blocks) , um Mo- 
delle 150 fur die jeweilige Phase zu erzeugen. Ein Datenob- 
jekt 300 wird vorzugsweise nicht vom zentralen 
Diensteprogramm 98 erzeugt, geandert, geloscht und verwaltet, 
sondern von der jeweiligen Anwendung 200. Die Anwendung 150 
stellt insbesondere die dauerhafte Speicherung des Datenob- 
jekts 300 z. B. in einer lokalen Datenbank 110 sicher. Das 
Datenobjekt 300 ist Bestandteil eines Produkt- oder ProzeSmo- 
dells 150 und steht in der Regel nur der erzeugenden Anwen- 
dung 200 zur Verfugung, aber keiner anderen Anwendung. 

Das zentrale Diensteprogramm 98 vermag ein Datenobjekt 3 00 li- 
ber ein Zugrif f sverf ahren anzusprechen, z. B. mit Hilfe eines 
Zugrif f spf ades auf das Produkt- oder ProzeSmodell 150 und ei- 
ne innerhalb dieses Modells eindeutige Kennung (identifier) 
oder uber eine Programmierschnittstelle (application program- 
ming interface, API) zu einer Anwendung 200. Eine in der 
zentralen Datenbank 100 gespeicherte Relation 400.1 besitzt 
Verweise auf die Datenobjekte 300.1 und 3 00.3, die durch die 
Relation 400.1 verbunden werden. Diese Verweise umfassen alle 
Inf ormationen, die das zentrale Diensteprogramm 98 fur einen 
lesenden Zugrif f auf die Datenobjekte 300.1 und 300.3 beno- 
tigt . 
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Eine Anwendung 200 kann uber eine Inf ormationsweitergabe- 
Schnittstelle 250 und das zentrale Diensteprogramm 98 die Er- 
zeugung und dauerhafte (persistente) Abspeicherung eines Da- 
tenobjekt-Typs 500 in der zentralen Datenbank 100 auslosen. 
Umgekehrt kann die Anwendung 200 sich Inf ormationen uber Da- 
tenobjekt -Typen 500 aus der zentralen Datenbank 100 beschaf- 
fen, z. B. urn ein Datenobjekt 3 00 eines bestimmten Datenob- 
jekt-Typs 500 durch Instantiierung zu erzeugen. Beispielswei- 
se wird uber eine Inf ormationsweiterleitungs-Schnittstelle 
250 an ein CAD-Werkzeug als eine Anwendung 2 00 geschickt, 
durch Instantiierung ein Datenobjekt 300 eines vorgegebenen 
Datenobjekt -Typs 500 zu erzeugen. Das erf indungsgemafie System 
10 gibt einer Anwendung 2 00 den Typ 500 sowie den Namen und 
bestimmte Attribute und/oder Methoden des zu erzeugenden Da- 
tenobjekt s 3 00 vor. 

Bevor eine Anwendung 200.1 eine von ihr erzeugtes und verwal- 
tetes Datenobjekt 3 00.1 loscht, ermittelt das zentrale 
Diensteprogramm 98, welche anderen Datenobjekte 300.3 dersel- 
ben oder anderer Anwendungen von dieser Loschung beeinflu&t 
werden. Hierfiir wird folgende Abfolge automatisch ausgeftihrt, 
vgl . Fig . 1 : 

- Die Anwendung 200.1 ubermittelt an das zentrale 
Diensteprogramm 98 eine Kennung sowie den Typ 500.1 des zu 
loschenden Datenobjekt s 3 0 0.1. 

- Das zentrale Diensteprogramm 98 ermittelt mittels Lese- 
zugriff auf die zentrale Datenbank 10 0, durch welche Rela- 
tions-Typen der Datenobjekt -Typ 500.1 mit anderen Datenob- 
jekt-Typen verbunden ist. Seien 600.1, ... , 600. n diese 
Typen. 

- Das zentrale Diensteprogramm 98 ermittelt die m Relationen 
400.1, ... , 400. m, die von einem der Typen 600.1, ... , 
60 0.n oder einem Untertyp dieser n Typen sind und die je 
einen Verweis auf das Datenobjekt 300.1 tragen. 

- Das zentrale Diensteprogramm 98 ermittelt, welche anderen 
Datenobjekte 300.3, 300.5 mindestens einer dieser m Rela- 
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tionen zugeordnet sind. Diese Datenobjekte werden von der 
geplanten Loschung beeinf lu£t . 

Das zentrale Diensteprogramm 98 ermittelt, welche automa- 
tisch auswertbaren Vorschriften den n Relations-Typen 
600. 1, ... , 600. n zugeordnet sind. Durch Auswertung die- 
ser Vorschriften ermittelt das zentrale Diensteprogramm 98 
weitere Konsequenzen der geplanten Loschung, z. B. Veran- 
derung von Parametern oder Loschung weiterer Datenobjekte. 

- Das zentrale Diensteprogramm 98 ermittelt, welche Anwen- 
dungen 200.1, 200.3 mindestens eines dieser beeinf lufiten 
weiteren Datenobjekte 300.3, 300.5 verwalten, und ubermit- 
telt je eine Beschreibung der Auswirkungen an die jeweili- 
ge Anwendung 200.1, 200.3. 

Z. B. durch Abarbeitung eines Arbeitsablauf s (workflow) 
werden die erf orderlichen Freigaben fur die Loschung von 
300.1 eingeholt. 

- Nach der Loschung streicht das zentrale Diensteprogramm 98 
alle Verweise auf das geloschte Datenobjekt 300.1 aus den 
Relationen 400.1, ... , 400. m. Bei Bedarf werden Relatio- 
nen geloscht. 

Eine alternative Aus fuhrungs form sieht vor, dafi die Anwendung 
200.1 das Datenobjekt 300.1 loscht und die Information uber 
die Loschung erst nachtraglich an das zentrale 
Diensteprogramm 98 ubermittelt. 

Eine entsprechende Abfolge wird z. B. ausgefiihrt, urn Informa- 
tionen daruber zu erzeugen, mit welchen weiteren Datenobjek- 
ten ein zuvor ausgewahltes typisiertes erstes Datenobjekt 3 00 
in Verbindung steht . Diese Inf ormat ionen werden entweder 
durch direkte Auswertung von Inf ormat ionen oder bei spiel swei- 
se durch die f olgende Abfolge erzeugt : 

Ein typisiertes Datenobjekt wird ausgewahlt. 

- Der Datenobjekt -Typ dieses Datenobjekts wird ermittelt. 

- Alle Relations-Typen, denen dieser Datenobjekt -Typ zuge- 
ordnet ist, werden ermittelt. 
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- Alle weiteren Datenobjekt-Typen werden ermittelt, die ei- 
nem dieser Relations-Typen zugeordnet sind. 

- Alle Datenobjekte dieser Typen werden ermittelt. 

Das erf indungsgemaSe System 10 umf aSt Komponenten zur Durch- 
fiihrung dieser Ermittlungen. 

Das zentrale Diensteprogramm 98 regelt den Kontroll- und In- 
f ormationsf luS zwischen den Anwendungen 2 00 sowie zwischen 
einer Anwendung 200 und der zentralen Datenbank 100. Es be- 
antwortet Anfragen, die von einer Anwendung 200 uber eine In- 
f ormationsweiterleitungs-Schnittstelle 250 eingehen, lost Er- 
eignisse wie die Erzeugung eines Datenobjekts 300 aus und 
verwaltet die zentrale Datenbank 100 einschlieSlich der Tran- 
saktions-Verwaltung fur die dauerhafte Speicherung von Daten- 
objekten 300 und Relations-Typen 600, Relationen 400 und Re- 
lations -Typ-Kategorien. 

Das zentrale Diensteprogramm 98 greift z. B. mit Hilfe von 
Standard-Protokollen wie „Open Database Connectivity w (ODBC) 
auf eine relationale Datenbank, die als zentrale Datenbank 
100 fungiert, zu. Zum Abfragen dieser relationalen Datenbank 
wird z. B. die „Standard Query Language" (SQL) als Standard- 
sprache fur Abfragen von relationalen Datenbanken verwendet . 
Eine alternative Aus fuhrungs form sieht vor, zwischen zentra- 
lem Diensteprogramm 98 und zentraler Datenbank 100 funktiona- 
le oder objekt-orientierte Schnittstellen in Verbindung mit 
definierten Programmier-Schnittstellen fur Anwendungen (ap- 
plication programming interfaces, APIs) bereitzustellen. Das 
zentrale Diensteprogramm 98 nutzt Funktionalitaten von Pro- 
grammier-Schnittstellen, urn Lese- und/oder Schreibzugrif f auf 
die zentrale Datenbank 100 zu erhalten. Ein Vorteil der XML- 
Dateien ist ihre einf ache Handhabbarkeit . ODBC und SQL sind 
weit verbreitete Standards. Viele Software- 

Entwicklungsumgebungen besitzen ODBC- und SQL-Schnittstellen . 
Ein Vorteil von Programmier-Schnittstellen ist der, daS die 
Art der Datenspeicherung nach auJSen nicht sichtbar ist und 
daher die zentrale Datenbank 100 intern geandert werden kann, 
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ohne daS deshalb das zentrale Diensteprogramm 98 oder gar An- 
wendungen 2 00 geandert zu werden brauchen. Anwendungen und 
das zentrale Diensteprogramm 98 werden vorzugsweise durch In- 
ter -Prozefi-Kommunikat ion miteinander verbunden, z. B. auf Ba- 
sis von distributed Component Object Model n (DCOM) , ^Hyper- 
text Transfer Protocol w (HTTP) oder „Common Object Request 
Broker Architecture " (CORBA) mit einer „ Interface Definition 
Language " (IDL) oder „ Enterprise Java Beans" (EJB) . 

Moglich ist, dafi das zentrale Diensteprogramm 98 und weitere 
Komponenten des erf indungsgemaSen Systems 10 und zumindest 
einige Anwendungen 200 alle auf derselben Datenverarbeitungs- 
anlage ablaufen. Vorzugsweise umfaSt das erf indungsgemaSe 
System 10 aber eine eigene Datenverarbeitungsanlage , die als 
Ne t zwerk- Zent ralrechner (Server) in einer Client -Server- 
Architektur fungiert. Die Datenverarbeitungseinrichtungen fur 
die Anwendungen 200 fungieren als Net zwerk-Teilnehmerrechner 
(Clients) . 

Die Erfindung unterstutzt die Integration verschiedener An- 
wendungen 200 in zwei Richtungen entlang des Produktentste- 
hungsprozesses: flufiabwarts (forward) und fluSaufwarts (back- 
ward) . Die Integration f luSaufwarts wird insbesondere dadurch 
erreicht, dafi die Auswirkungen einer Anderung in einer Phase 
auf nachfolgende Phasen ermittelt werden, z. B. von der Phase 
Konstruktion auf die Phase Fertigung oder auf die Phase Werk- 
zeugbau, in der abhangig von Produktmodellen 150 die zur Fer- 
tigung des Produkts benotigten Werkzeuge entworfen werden. 
Die Integration flufiabwarts hat zur Folge, daS Anwendungen 
200 in spateren Phasen uber Modelle 150 in fruheren Phasen 
informiert werden. Einzelnen Datenobjekten 3 00 dieser fruhe- 
ren Phasen, z. B. der Phase Produkt -Konstruktion, konnen 
z. B. Kons t rukt ions - Begrundungen (design rationale) zugeord- 
net sein, die zu besseren Entscheidungen in spateren Phasen 
fuhren . 

Die Erfindung unterstutzt durch die Integration beispielswei- 
se Kostenvorhersage (cost estimation) , Produktentwurf mit ei- 
nem vorgegebenen Optimierungskriterium und/oder vorgegebenen 
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Randbedingungen (design-to-X) , Automatisierung des Arbeitsab- 
laufs (workflow management) sowie die Handhabung von Erf ah - 
rungen, Rechtf ertigungen und Begrundungen . 

Fur die Kostenvorhersage ist insbesondere zu ermitteln, wel- 
che Kosten die Fertigung der Konstruktions- 

Gestaltungselemente des Produkts verursachen wird. Bei zu ho- 
hen Kosten sind einzelne Konstruktions-Gestaltungselemente so 
zu verandern, daS die gesamten Fertigungskosten sinken. Zu 
diesen Konstruktions-Gestaltungselementen zahlen beispiels- 
weise bestimmte Bohrlocher in Zylinderkopf en. Ein Datenob- 
jekt-Typ ^Bohrlocher im Zylinderkopf*' fur die Phase Produkt- 
Konstruktion sowie mindestens ein Datenobj ekt-Typ fur Ferti- 
gungs-Gestaltungselemente zur Fertigung der Bohrlocher werden 
eingefuhrt und durch einen Relations-Typ #/ wird gefertigt 
durch" miteinander verbunden. Die Fertigungs- 

Gestaltungselemente gehoren zu einem Produktmodell 150 fur 
die Arbeits- und Fertigungsplanung (machining planning) . Sie 
werden mit einer Anwendung 2 00 fur die Kostenvorhersage ver- 
bunden, die z. B. eine Datenbank 110 mit Datensatzen fur 
Werkzeuge, Bearbeitungszeiten und Stundensat zen umf a6t . Dank 
der Erfindung hat die Anwendung 200, die das Produktmodell 
150 mit den Konstruktions-Gestaltungselementen bearbeitet, 
Lesezugriff auf die Kosteninf ormationen und kann veranlassen, 
daS die Kosten fur die Fertigung des Bohrlochs vorhergesagt 
werden. 

Die Versorgung und die Integration werden erf indungsgemafi 
durch zwei Merkmale realisiert. Datenobj ekt-Typen fur ver- 
schiedene Phasen werden semantisch dadurch verknupft, daS sie 
in einer einzigen Taxonomie zusammengef aSt werden. Dadurch 
wird eine gemeinsame Notation z. B. von Typen und Attributen 
fur alle Phasen sichergestellt , Redundanz und doppelte Daten- 
haltung werden vermieden. Nicht erforderlich ist es, Trans - 
formationen zwischen Modellen fur verschiedene Phasen zu er- 
zeugen und auszuwerten. Wie oben beschreiben, spart der Ver- 
zicht auf Transf ormationen insbesondere viele Schnittstellen 
ein. 
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Fig. 3 zeigt einen Ausschnitt aus der anwendungs- und phasen- 
ubergreif enden Taxonomie fur Datenobjekt-Typen. Ein Rechteck 
reprasentiert einen Datenobj ekt-Typ . Eine Kante verbindet ei- 
nen Untertyp mit dem oberhalb des Untertyps gezeigten Ober- 



Bezugs- 
zeichen 


Name des Datenobjekt-Typs 


500.1 


Abstrakter Typ „Datenobjekt-Typen" (engineering ob- 
ject types) 


500.2 


Gestaltungselemente der Benutzeroberf lache (user in- 
terface features) 


500.3 


Gestaltungselemente eines produktiv eingesetzten 
CAD-Werkzeugs xyz (xyz features) 


500.29 


Gestaltungselemente (features) 


500.4 


Bauteile des Produkts (parts) 


500.5 


Qualitats-Gestaltungselemente (quality features) 


500.6 


Konstrukt ions -Gestaltungselemente 
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DUU . / 
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r ci uiyuiiy b vjco LaiLuiiyociciutiiiLc v niaiiuLaL. L.U.X xiiy lea 

tures) 


500.8 


Rohteil -Gestaltungselemente (raw part features) 


500.9 


Pruf -Gestaltungselemente (inspection features) 


500. 10 


fur eine GieSform benotigtes Bauteil (mold parts) 


500.28 


MeS-Gestaltungselemente (measure elements) 


500.11 


Bleche (sheet metals) 


500.12 


geometrischer Grundkorper (volumetric features) 


500.30 


Zerspanungs- Gestaltungselemente (machining features) 


500.13 


Rohteil -Zylinder (raw part cylinders) 


500. 14 


Auswerf er (ejectors) 


500.15 


Abziehende Grundkorper ( subtract ive features) 
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500.22 


Zusammengesetztes Bohrlocher (complex holes) 


500.23 


Sacklocher (blind holes) | 


500 .24 


Durchgangslocher (through holes) 


500 .25 


Sacklocher mit Aufbohrung (debored blind holes) 


500 .26 


Durchgangslocher mit Aufbohrung 
(debored through holes) 


500 . 27 


Zundkerzen-Bohrlocher (spark plug holes) 



In diese Taxonomie lassen sich insbesondere alle Typen von 
Gestaltungselementen einordnen, die aus DIN 32869-3 bekannt 
sind. 



Datenobjekte , insbesondere Konstruktions-Gestaltungselemente 
(design features) und Fertigungs-Gestaltungselemente (manu- 
facturing features) , werden vorzugsweise gemafi dem objektori- 
entierten Paradigma behandelt, das aus J. Rumbaugh, M. Blaha, 
W. Premerlani, F. Eddy, W. Lorenson: „ Object -Oriented Model- 
ling and Design", Prentice-Hall, Englewood Cliffs, 1991, be- 
kannt ist. Datenobjekte 3 00 werden typisiert, und Typen 500 
(types / classes) von Datenobjekten konnen Attribute oder Pa- 
rameter, die die statischen Eigenschaf ten der Datenobjekte 
beschreiben, und Methoden fur die dynamischen Eigenschaf ten 
der Datenobjekte besitzen. 

Ein Datenobjekt 300 eines vorgegebenen Datenobj ekt-Typs 500 
lafit sich durch „ Instant iierung" des Datenobj ekt-Typs erzeu- 
gen. Das so erzeugte Datenobjekt besitzt die Attribute und 
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Methoden des Datenobjekt -Typs . Urn Redundanz unter Typen von 
Datenobjekten zu verringern, werden bevorzugt mehrere Abs- 
traktionsschritte durchgefuhrt. Dabei werden Gemeinsamkeiten 
zwischen n Datenobjekt -Typen 500. 1, ... , 500. n identif iziert 
und in einem neuen, abstrakteren Datenobjekt -Typ zusammenge- 
faSt. Dieser neue Datenobjekt -Typ 500. o wird Obertyp (parent) 
von 500.1, ... , 500. n. 500. o ist mit 500.1, ... , 500. n 
durch eine Spezialisierungs-Relation verbunden. Das Ergebnis 
der Abstraktionsschritte ist eine Taxonomie unter Datenob- 
jekt-Typen 500. Blatter dieser Taxonomie, also Datenobjekt- 
Typen ohne Unter typen, konnen instant iiert werden, die abs- 
trakteren Datenobjekt -Typen vorzugsweise nicht. 

Fur die erf indungsgemafien Relationen 400 zwischen Datenobjek- 
ten 300 werden entsprechende Typisierungen durchgefuhrt. Da- 
durch entstehen Relations-Typen 600, aus denen durch Instan- 
tiierung Relationen 400 erzeugt werden konnen. Durch entspre- 
chende Abstraktionen der Relations-Typen 600 werden Relati- 
ons -Typ- Kategorien und eine Taxonomie unter diesen Relations- 
Typ-Kategorien erzeugt. 

Eine Relation 4 00 verbindet mindestens zwei Datenobjekte 
300. a und 300. b. Eine Relation 400 fungiert als Baustein 
(building block) fur die Verwaltung und Auswertung der Abhan- 
gigkeiten zwischen Datenobjekten 300. a, 300. b. Eine Relation 
400. a kann auch eine andere Relation 400. b mit einem oder 
mehreren Datenobjekten 300. a, 300. b verbinden oder aber meh- 
rere andere Relationen miteinander verbinden. Entsprechend 
verbindet ein Relations-Typ 600 mindestens zwei Datenobjekt- 
Typen 500. a und 500. b miteinander. Ein Relations-Typ 600. a 
kann auch einen anderen Relations-Typ 600. b mit einem oder 
mehreren Datenobjekt -Typen 500 verbinden oder aber mehrere 
andere Relations-Typen miteinander verbinden. 

Ein Beispiel fur eine Relation, die andere Relationen mitein- 
ander verbindet, sind Datenobjekte und Relationen fur ein 
Lochbild, das sind mehrere Locher mit bestimmten Posit ionen 
relativ zueinander, die aus einem Blech ausgestanzt werden. 
Ein Datenobjekt -Typ „Bohrl6cher u mit den beiden Untertypen 
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„Ref erenz-Bohrlocher" und „abhangige Bohrl6cher w werden ein- 
gef uhrt . Die n Locher eines Lochbildes werden durch ein Da- 
tenobjekt des Typs „Ref erenz - Bohr 1 ocher " und n-1 Datenobjekte 
des Typs „abhangige Bohrl6cher M reprasentiert. Die absolute 
Soli-Position des Ref erenz -Bohrlochs und die relativen Posi- 
tionen der n-1 abhangigen Bohrlocher werden vorgegeben und 
durch entsprechende Attribute reprasentiert. Weiterhin werden 
ein Datenobjekt des Typs „Lagetoleranz" und n-1 Datenobjekte 
des Typs /f Me£-Toleranzen w erzeugt und dem Ref erenz -Bohr loch 
bzw. den n-1 abhangigen Bohrlochern mittels Relationen zuge- 
ordnet . 

Ein Relations-Typ „Relativposition" und n-1 Relationen dieses 
Typs werden erzeugt. jede Relation dieses Typs verbindet das 
Ref erenz -Bohrloch, ein abhangiges Bohr loch und eine Mefi- 
Toleranz miteinander. Der Relations-Typ „Relativposition" ist 
mit den Datenobj ekt-Typen „Ref erenz -Bohrlocher" , „abhangige 
Bohrlocher w und „Me£-Toleranzen" verbunden. Er umfaSt eine u- 
berprufende Vorschrift fur die Relativ-Position des abhangi- 
gen Bohrlochs relativ zum Ref erenz-Bohrloch des Lochbildes. 
Die Vorschrift nimmt Bezug auf die durch das dritte Datenob- 
jekt vorgegebene MeStoleranz. Jede Relation des Typs Rela- 
tiv-Position" „kennt" diese Vorschrift. Bei Auswertung der 
Relation ermittelt das erf indungsgemaSe System 10 die beno- 
tigten Attribute der drei Datenobjekte und setzt sie in die 
Vorschrift ein. Uberpruft wird durch die Auswertung der Vor- 
schrift , ob die Relativ-Position die vorgegebene MeStoleranz 
einhalt. Ein weiterer Relations-Typ namens „Lochbilder u wird 
eingefiihrt. Pro Lochbild wird eine Relation dieses Typs er- 
zeugt, welche die gerade beschriebenen n-1 Relationen des 
Typs „Relativ-Position u miteinander verbindet. Uber diese Re- 
lation kann das zentrale Diensteprogramm 98 auf alle Datenob- 
jekte und Relationen, die das Lochbild reprasentieren, 
zugreif en. 

Eine abweichende Ausf uhrungsf orm dieses Beispiels sieht vor, 
N Untertypen des Datenobjekt -Typs „abhangige Bohrlocher" zu 
erzeugen, wobei N die maximal mogliche Loch-Anzahl eines 
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Lochbildes ist. Die n-1 Datenobjekte fur die n-1 abhangigen 
Bohrlocher des Lochbildes gehoren zu n-1 verschiedenen der N 
Datenobjekt-Typen. Dank dieser Ausf uhrungsf orm laSt sich 
durch Kenntnis nur des jeweiligen Datenobjekt-Typs ein be- 
st immtes abhangiges Bohrloch adressieren. 

Sonderfalle von Datenobjekt-Typen sind die Typen w Kommenta- 
re M , w Benutzer-Hilfen tt , „Erf ahrungsobjekte" und „Dokumentati- 
onen u . Ein Erf ahrungsobjekt umfaSt Texte, Bilder und/oder 
Bildfolgen, die Erfahrungen mit einem anderen Datenobjekt o- 
der einer Relation oder Begriindungen z. B. fur eine Entwurfs- 
entscheidung (design rationale) beschreiben. Fur alle diese 
Typen wird der Obertyp „Erlauterungen w eingefuhrt. Ein Daten- 
objekt des Typs „Erlauterungen" ist durch eine Relation mit 
mindestens einem anderen Datenobjekt, z. B . einem Gestal- 
tungselement oder einem Bauteil, einem Datenobjekt-Typ oder 
einer Relation oder einem Relations-Typ oder einer Relations- 
Typ-Kategorie verbunden. Dieselbe Erlauterung kann verschie- 
denen Datenobj ekten zugeordnet sein. Moglich ist, eine Erlau- 
terung zunachst einem Datenobjekt zuzuordnen und spater nach 
einem FreigabeprozeiS dem entsprechenden Datenobjekt-Typ. Die 
Relationen zwischen Erlauterungen einerseits und anderen Da- 
tenobj ekten, Relationen, Typen oder Relations -Typ-Kategorien 
andererseits werden ebenfalls typisiert, z. B. gehoren sie 
alle einem Relations-Typ /; Erlauterungs - Zuordnung " an. 

In Abhangigkeit von den automatisch auswertbaren Vorschriften 
werden zwei Arten von Relationen unterschieden, namlich uber- 
pruf ende und generische Relationen. Entsprechend werden uber- 
pruf ende und generische Relations -Typen unterschieden . 

Ein uberpruf ender Relations-Typ beschreibt durch die zugeord- 
neten uberpruf enden Vorschriften mindestens eine logische Ab- 
hangigkeit zwischen Datenobj ekten. Gepruft wird, ob die exis- 
tierenden Datenobjekte mit den Vorschriften vereinbar sind. 
Neue Datenobjekte werden nicht erzeugt . Eine Sonderform einer 
uberpruf enden Vorschrift ist ein Attribut des Relat ions- Typs . 
Dieses Attribut kennzeichnet beispielsweise eine Relation und 
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damit eine Abhangigkeit zwischen Datenobj ekten verschiedener 
Anwendungen 200. 1 , 200.2 naher . 

Ein Beispiel: Ein Zylinderkopf umfaiSt n Kuhlrippen. Diese 
werden in der Phase Konstruktion durch n Konstruktions- 
Gestaltungselemente modelliert. Ein Grundkorper fur den Zy- 
linderkopf wird urn diese n Konstruktions-Gestaltungselemente 
erganzt . Bei der Fertigung des Zylinderkopf s werden die Kuhl- 
rippen erzeugt, indem Aussparungen aus einem Block gefrast 
werden. Diese auszuf rasenden Aussparungen werden in der Phase 
Arbeitsplanung durch Fertigungs-Gestaltungselemente model- 
liert. Urn die Abhangigkeiten zwischen diesen Gestaltungsele- 
menten zu erfassen, wird ein Typ von Relationen zwischen n 
Konstruktions-Gestaltungselementen fur die Phase Konstruktion 
und m Fertigungs-Gestaltungselementen fur die Phase Arbeits- 
planung eingefuhrt. Eine solche Relation verbindet n Kuhlrip- 
pen und m Ausfrasungen an einem Zylinderkopf. 

Urn festzulegen, wie viele Datenobj ekte diese Relation verbin- 
det, werden zwei Mitgliedschaf ts-Intervalle (Kardinalitaten) 
fur den Relations-Typ festgelegt. Das erste Mitgliedschaf ts- 
Intervall schrankt die Anzahl der Kuhlrippen ein, das zweite 
die Anzahl der Ausfrasungen. Ein Mitgliedschaf ts-Intervall 
hat z. B. die Form a:b, wobei a eine naturliche Zahl und b 
eine naturliche Zahl oder * ist. Die Festlegung * steht fur 
eine beliebig grofie Anzahl von Datenobj ekten . 

Vorzugsweise werden dem Relations-Typ weiterhin zwei fremde 
Rollen zugeordnet, namlich die Rollen „als Konstruktions- 
Gestaltungselemente" und «als Fertigungs- 

Gestaltungselemente u . Dadurch wird festgelegt, welche Rollen 
die verbundenen Datenobj ekte in einer Relation des Typs „aus 
Sicht der Rolle" spielen. Im allgemeinen Fall sind vorzugs- 
weise n Mitgliedschaf ts-Intervalle und n Rollen fur einen Re- 
lations-Typ festgelegt, die n Datenobj ekt-Typen und/oder Re- 
lations-Typen miteinander verbindet. Diese Ausgestaltung er- 
moglicht es, effizient m: n-Beziehungen zu modellieren. 
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Weiterhin wird einem Relations-Typ eine Kennzeichnung der ei- 
genen Rolle zugeordnet , das ist die Rolle, die eine Relation 
des Typs aus Sicht der verbundenen Datenobjekte spielt . Der 
Unterschied zwischen fremden Rollen und eigener Rolle wird an 
folgendem Beispiel erlautert: 

Zwei Datenobjekt-Typen „Konstrukt ions -Gestaltungselemente" 
(design features) und „ Fertigungs-Gestaltungselemente" (manu- 
facturing features) werden erzeugt. Der Datenobjekt-Typ „Kon- 
struktions-Gestaltungselemente" hat u. a. den Untertyp „Zwei- 
Stuf en-Bohrlocher * , der Dat enob j ekt -Typ „ Fertigungs- 
Gestaltungselemente" den Untertyp w Bohrungen w . „ Zwei-Stuf en- 
Bohrlocher" und „Bohrungen" werden einem Relations-Typ „wird 
gefertigt als" so zugeordnet, daS eine Relation des Typs ein 
Zwei-Stuf en-Bohrloch mit zwei Bohrungen verbindet . Dem Rela- 
tions-Typ werden die eigenen Rollen „ Fert igungs - S icht 11 (aus 
Sicht der Konstruktions-Gestaltungselemente) und „Fertigteil- 
Sicht" (aus Sicht der Fert igungs -Gestaltungselemente) zuge- 
ordnet. Weiterhin werden dem Relations-Typ die fremden Rollen 
„obere Bohrung" und „untere Bohrung" (aus Sicht des Zwei- 
Stuf en-Bohrlochs) sowie „Stuf en-Bohrloch" (aus Sicht der Boh- 
rungen) zugeordnet . 

Die dem Relations-Typ namens „wird gefertigt durch" zugeord- 
nete Vorschrift legt z. B. fest, welche und wie viele Ferti- 
gungs - Ge s t al t ung s e 1 ement e fur gegebene Kons t rukt i ons - 
Gestaltungselemente erforderlich sind. Die iiberpriifende Vor- 
schrift besagt z. B., daS m = n - 1 gelten muS. Sie kann Be- 
zug auf die beiden Mitgliedschaf ts-Intervalle nehmen. Falls 
beispielsweise zehn Konstrukt ions -Gestaltungselemente, aber 
nur fiinf Fertigungs-Gestaltungselemente erzeugt wurden, so 
wird durch Anwendung der Vorschrift ein Widerspruch entdeckt 
und gemeldet . 

Die fehlenden Fertigungs-Gestaltungselemente werden nicht au- 
tomatisch erzeugt. Es liegt in der Verantwortung der jeweili- 
gen Anwendung 200, an die der Widerspruch gemeldet wird, oder 
ihrer Benutzer, diesen zu beseitigen. 
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Uberpruf ende Relationen konnen auch sogenanntes ontologisches 
Wissen uber semantische Zusammenhange zwischen Datenobjekt- 
Typen besitzen. Sie erlauben einen konsistenten Informati- 
onsfluS entlang des Produktentstehungsprozesses und verkrnip- 
fen Anwendungen auf der Inf ormationsebene und nicht nur auf 
der Datenebene. 

Eine generierende Relation umfaSt mindestens eine automatisch 
auswertbare Generierungsvorschrif t , die festlegt, wie Daten- 
objekte automatisch erzeugt werden. Diese Vorschrift ist ei- 
nem Typ generierender Relationen zugeordnet und legt das ge- 
wiinschte Ergebnis eines Generierungsschritts fest. Vorzugs- 
weise ubermittelt das zentrale Diensteprogramm 98 dieses ge- 
wunschte Ergebnis an die jeweiligen Anwendungen 200. Es liegt 
in der Verantwortung dieser Anwendungen 2 00 und bei Bedarf 
ihrer Benutzer, das gewunschte Ergebnis zu erzeugen. 

Diese Vorschriften konnen von Bedingungen in Produktmodellen 
150 abhangen oder von diesen Oder von anderen definierten Er- 
eignissen (events) ausgelost werden. Beispielsweise wird nach 
jeder Anderung eines anwendungsspezif ischen Modells fur eine 
Phase ermittelt, welche Datenobjekte von der Anderung 
beeinfluSt sind und welche generierenden Relationen sich auf 
diese Datenobjekte beziehen. Eine Anderung des Produkt- 
Modells lost eine automatische Auswertung der aufgrund der 
Anderung ermittelten generierenden Relationen aus . Generie- 
rende Relationen automat isieren damit Aufgaben des Produkt- 
entstehungsprozesses . 

Vorzugsweise verknupft eine generierende Relation die Daten- 
objekte, die einen Generierungsschritt auslosen, mit denjeni- 
gen Datenobj ekten # die bei diesem Generierungsschritt erzeugt 
werden, z. B. durch „ Instantiierung" . Die Generierungsvor- 
schrift, die dem jeweiligen Typ generierender Relationen zu- 
geordnet ist, umfaSt alle Inf ormationen, die erforderlich 
sind, urn Datenobjekte in einem bestimmten Produkt- oder Pro- 
zeJSmodell zu instant iieren. 
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Eine von einer generierenden Relation umfaSte Vorschrift ge- 
neriert z. B. eine Gruppe von miteinander durch Relationen 
verbundenen Gestaltungselemente (feature constellation) . 
Nicht nur die Datenobj ekt- Typen werden instant i iert , um die 
verbundenen Gestaltungselemente zu erzeugen, sondern auch die 
Relations -Typen, um die verbindenden Relationen zu erzeugen. 
Ein Generierungsschritt wird beispielsweise immer dann ausge- 
lost, wenn ein vorab spezif iziertes Datenobj ekt verandert o- 
der instantiiert wird. Die Festlegung, wodurch ein Generie- 
rungsschritt ausgelost wird, wird erf indungsgemaS einem Rela- 
tions-Typ zugeordnet . Eine Vorschrift, die einem Relations - 
Typ zugeordnet ist, wird beispielsweise von einer Komponente 
des erf indungsgemaSen Systems 10 interpret iert . Oder aber das 
zentrale Diensteprogramm 98 leitet die Vorschrift an eine In- 
f erenzmaschine 60 weiter, welche die automat ische Auswertung 
vornimmt und ihr Ergebnis, also das gewunschte Ergebnis einer 
Generierung, an das zentrale Diensteprogramm 98 zuruckmeldet . 
Weil die Inf erenzmaschine 60 komplexe Auswertungen durch- 
fuhrt, ist es oft von Vorteil, sie als eigene Anwendung ge- 
trennt vom zentralen Diensteprogramm 98 zu realisieren. 

Die Verwendung von Relations-Typ-Kategorien, Relations -Typen 
und Relationen wird an einem Beispiel erlautert. Fur einen 
ProduktentstehungsprozeS eines Automobil -Herstellers , der fur 
jede seiner neuen Baureihen gultig ist, wird in der anwen- 
dungsubergreif enden Standard-Bibliothek ein Datenobj ekt- Typ 
„L6cher xx eingefuhrt und der Phase Produkt-Konstruktion zuge- 
ordnet. Die Datenobjekte dieses Typs sind Konstruktions- 
Gestaltungselemente (design features) . Weiterhin wird ein Typ 
von Qualitats-Gestaltungselementen (quality features) namens 
„Funktions-Toleranzen u mit den Untertypen „ Formtoleranzen w , 
„Lagetoleranzen w und „Mefitoleranzen w eingefuhrt und der Phase 
„Konstruktion w zugeordnet. Der Typ „L6cher" erhalt einen Un- 
tertyp „Bohrlocher n und dieser einen Untertyp „Bohrlocher fur 
Karosserie". Diese Ausgestaltung beriicksichtigt , daS die Kon- 
strukteure bereits in der Phase „Konstruktion" funktionale 
Toleranzen z. B. fur Konstrukt ions -Gestaltungselemente fest- 



WO 2004/003798 (^jf PCT/EP2003/006270 

35 



legen. In der Phase w Produkt ionspl anung M werden weitere Tole- 
ranzen festgelegt, z. B. solche zur Uberwachung des Ferti- 
gungsprozesses und insbesondere der zur Herstellung des Pro- 
dukts verwendeten Bearbeitungsmaschinen und Werkzeuge . 

Der Phase Qualitatssicherung wird ein Typ von MeS- 
Gestaltungselementen (measuring features) namens „Me£punkte u 
zugeordnet. Jedes MeS-Gestaltungselement reprasentiert einen 
Abtastpunkt, dessen tatsachliche Position und/oder Orientie- 
rung wahrend der Qualitatssicherung ermittelt und mit einer 
Soil-Position und/oder Soli -Orient ierung verglichen wird. 

Drei Kategorien von Datenobjekten werden erzeugt , namlich die 
Kategorie der Konstruktions-Gestaltungselemente, die der Qua- 
litats-Gestaltungselemente und die der MeS- 

Gestaltungselemente . Eine Relations-Typ-Kategorie namens 
„MeSstrategien u wird eingefuhrt. Festgelegt wird, 

daS ein Relations-Typ dieser Kategorie drei Datenobjekt- 
Typen verbindet, namlich einen Typ von Konstruktions- 
Gestaltungselementen einen Typ von Qualitats- 
Gestaltungselementen und einen Typ von Me£- 
Gestaltungselementen, 

und welche Parameter ein Relations-Typ der Kategorie min- 
destens haben mu£, vorzugsweise mindestens einen Namen und 
eine Mefistrategie, formuliert z. B. mit Hilfe der Dokumen- 
ten-Beschreibungssprache „ extended Markup Language" (XML) 
oder als Freitext. 

Jeder Relations-Typ der Kategorie „Me&strategien" verbindet 
somit einen Typ von Konstruktions-Gestaltungselementen, einen 
Typ von Qualitats -Gestaltungselementen und einen Typ von Me&- 
Gestaltungselementen miteinander . 

Ein uberpriif ender Relations-Typ der Kategorie „MeSstrategien" 
wird erzeugt, mit dem Namen „wird uberpruft durch" versehen 
und der Kategorie „MeSstrategien" zugeordnet. Der Relations- 
Typ „wird uberpruft durch" verbindet drei Datenobj ekt-Typen 
miteinander, namlich die Typen „Bohrl6cher w , r/ Loch-Toleranz w 
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und w Mefipunkte w . Diesem Relations-Typ wird z. B. folgende u- 
berprufende Vorschrift zugeordnet : 

Fur jedes Konstruktions-Gestaltungselement k, jedes Quali- 
tats-Gestaltungselement qu und jedes MeS-Gestaltungselement m 
gilt: 

Falls der Typ von k gleich „Bohrl6cher fur Karosserie" ist, 
gilt: 

Falls der Durchmesser von k kleiner als 0,5 mm ist und die 
Toleranz von qu grofier 0,1 mm ist, dann ist die Anzahl von m 
gleich 5. 

Falls der Durchmesser von k kleiner als 0,5 mm ist und die 
Toleranz von qu kleiner gleich 0,1 mm ist, dann ist die An- 
zahl von m gleich 8 . 

Falls der Durchmesser von k zwischen 0,5 mm und 5 mm ist, 
dann ist die Anzahl von m gleich 10. 

Falls der Durchmesser von k groSer als 5 mm ist, dann ist die 
Anzahl von m gleich 20. 

Die „ Anzahl von m" bezeichnet die Anzahl von MeSpunkten, die 
dem Bohrloch zugeordnet sind und mit denen die Einhaltung der 
geforderten Toleranz uberpruft wird. 

AuSerdem ermoglicht die Erfindung eine „bidirektionale Asso- 
ziativitat" zwischen Datenobjekt-Typen. Dies wird am folgen- 
den Beispiel erlautert . Zwei Datenobjekt-Typen A und B besit- 
zen die drei Parameter x und y (Parameter von A) bzw. z (Pa- 
rameter von B) . Eine automatisch auswertbare iiberprufende 
Vorschrift legt fest, daS B.z = A.x * A.y ist. Falls zwei 
dieser drei Parameter bekannt sind, laSt sich der dritte au- 
tomatisch berechnen. Falls fur zwei Parameter obere und/oder 
untere Schranken bekannt sind, lassen sich eine obere 
und/oder untere Schranke fur den dritten Parameter aufstel- 
len. Beim Erzeugen der Vorschrift braucht nicht bekannt zu 
sein, welche die bekannten und welches der unbekannte Parame- 
ter sein wird. Werkzeuge zur automat ischen Gleichungs- und 
Ungleichungslosung (constraint solver) vermogen vielmehr eine 
mehr solche Gleichung automatisch nach der Unbekannten aufzu- 
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losen. Solche Werkzeuge sind z. B. aus WO 00/3164 0 A2 und 
US 5,477,450 bekannt . 

GemaS der Erfindung wird die Vorschrift B.z = A.x * A.y einem 
Relations -Typ R zugeordnet, dem die Datenobj ekt-Typen A und B 
zugeordnet sind. Falls eine Anwendung 2 00 ein Datenobj ekt b 
des Typs B erzeugt hat und der Wert fur b.z bestimmt werden 
soil, so wird f estgestellt , durch welche Relation b mit ande- 
ren Datenobj ekt en verbunden ist, und eine Relation r des Typs 
R wird hierdurch ermittelt. Durch Lesezugriff auf R wird die 
Vorschrift B.z = A.x * A.y ermittelt und automatisch ausge- 
wertet. Analog wird vorgegangen, wenn ein Datenobj ekt a des 
Typs A erzeugt wurde und der Wert fur a.x zu bestimmen ist. 

Wurde die Vorschrift B.z = A.x * A.y hingegen dem Datenob- 
j ekt -Typ B zugeordnet, so nuiSten dann, wenn der Wert fur a.x 
zu ermitteln ist, samtliche Datenobj ekt -Typen durchsucht wer- 
den, urn den Datenobj ekt -Typ B und dort eine anwendbare Vor- 
schrift zu finden. U. U. muSten hierfur sogar andere Anwen- 
dungen 2 00 konsultiert werden. 

Das erf indungsgemaSe System 10 automatisiert die Kooperation 
zwischen verschiedenen Anwendungen 2 00 und damit die Automa- 
tisierung von Aufgaben des Produktentstehungsprozesses uber 
verschiedene Phasen und Anwendungen 2 00 hinweg. Beispielswei- 
se ubermittelt eine Anwendung 200.1 an das zentrale 
Diensteprogramm 98, daS die Anwendung 200.1 ein Datenobj ekt 
300.1 eines vorgegebenen Typs durch Instant iierung erzeugen 
wird. Dieses Datenobjekt 300.1 gehort zu einem Produktmodell 
150.1, das durch die Anwendung 200.1 erzeugt und bearbeitet 
wird. Das zentrale Diensteprogramm 98 stellt den Typ 500.1 
des zu erzeugenden Datenobjekts 300.1 fest und ermittelt, 
welche Relations-Typen diesen Datenobj ekt -Typ 500.1 mit ande- 
ren Datenobj ekt -Typen verbinden. Falls es solche Relations- 
Typen nicht gibt oder falls diesem Relations-Typen aus- 
schlieSlich iiberprufende Vorschriften zugeordnet sind, meldet 
das System 10 an die Anwendung 200.1, daS die Erzeugung des 
Datenobjekts 300.1 fortgesetzt werden kann. Bei Bedarf uber- 
mittelt es Namen und Attributwerte fur das Datenobjekt 300.1 
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an die Anwendung 200.1. Falls hingegen ein Relations-Typ mit 
einer generierenden Vorschrift ermittelt wird, so wertet die 
Inf erenzmaschine 60 diese aus. Das Ergebnis hangt von dem zu 
erzeugenden Datenobjekt 300.1 des Typs 500.1 ab, beispiels- 
weise besteht es daraus, da£ n Datenobjekte eines Typs 500.2 
und r Datenobjekte eines weiteren Typs 500.3 sowie Relationen 
zwischen dem neuen Datenobjekt des Typs 500. 1, den n neuen 
Datenobjekten des Typs 500.2 und den r neuen des Typs 500.3 
zu erzeugen sind. Die Inf erenzmaschine 60 ubermittelt dieses 
Ergebnis an das zentrale Diensteprogramm 98. Das zentrale 
Diensteprogramm 98 ermittelt, welche Anwendungen 200 von die- 
sem Ergebnis beeinflufit sind, z. B. die auslosende Anwendung 
200.1 und/oder weitere Anwendungen. Jede beeinfluSte Anwen- 
dung 200. b erhalt die Mitteilung, welche Datenobjekte sie zu 
erzeugen hat, z. B. welche die n des Typs 500.2, welche die r 
des Typs 500.3. Die Erzeugung dieser Datenobjekte liegt in 
der Verantwortung der jeweiligen Anwendungen. Nachdem die An- 
wendungen 200 die Datenobjekte 300 fur ihre jeweiligen Pro- 
duktmodelle 150 vollstandig erzeugt haben, melden diese an 
das zentrale Diensteprogramm 98 zurxick, daS die Erzeugungs- 
Vorschlage ausgefuhrt wurden. 

Ein ahnlicher Ablauf wird ausgelost, wenn eine Anwendung 200 
ein bereits bestehendes Datenobjekt 300 verandert Oder loscht 
(change management) . Wird ein Relations-Typ 600 mit einer ii- 
berprufenden Vorschrift ermittelt, so wird diese angewendet, 
urn zu priifen, ob nach der Anderung immer noch ein konsis ten- 
ter Zustand vorliegt oder ob beispielsweise die Anderung eine 
automat isch ausfuhrbare und einem Relations -Typen zugeordnete 
Vorschrift verletzt. 

Das erf indungsgemaSe System 10 unterstutzt daruber hinaus die 
simultane Zusammenarbeit verschiedener Anwendungen 2 00 (con- 
current engineering) . Oft haben Anderungen, die eine erste 
Anwendung 200.1 an einem ersten Modell 150.1 des Produkts o- 
der Prozesses vornimmt, Auswirkungen auf ein zweites Modell, 
das von einer zweiten Anwendung 200.2 bearbeitet wird. Jedoch 
hat die erste Anwendung 200.1 keinen Schreibzugrif f auf das 
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zweite Modell 150.2, weil die Bearbeitung des zweiten Modells 
in der Verantwortung der Benutzer der zweiten Anwendung 200.2 
liegt.. In diesem Fall ermittelt das System 10, welche Daten- 
obj ekte des ersten Modells 150.1 von der Anderung betroffen 
sind. Es stellt fest, welche Relationen dieses Datenobjekt 
mit anderen Datenobj ekten verknupfen und welche Vorschriften 
den Typen dieser Relationen zugeordnet sind. Durch Auswertung 
dieser Vorschriften wird ermittelt, welche weiteren bereits 
exist ierenden Datenobj ekte wie verandert werden miissen und 
welche neuen Datenobj ekte erzeugt werden miissen, damit auch 
nach der Anderung das zweite und das erste Modell zueinander 
konsistent sind. Die dergestalt erzeugten Inf ormationen wer- 
den als Vorschlage an die zweite Anwendung 200.2 gesandt . Es 
liegt in der Verantwortung der Benutzer der zweiten Anwen- 
dung, ob diese Vorschlage realisiert werden oder nicht und 
wenn ja wie. 

Urn die Datenobjekt -Typen 500 und Relations -Typen 600 abzu- 
speichern, werden vorzugsweise eine Vorgehensweise und ein 
Datenmodell gewahlt, das unabhangig von einer bestimmten An- 
wendung ist. Eine Ausf uhrungsf orm sieht vor, die Syntax ex- 
tended Markup Language" (XML) mit „XML Schema Definition" 
(XSD) zu verwenden und Inf ormationen als ASCII -Text oder Text 
im Format Unicode abzuspeichern. Beispielsweise werden Inf or- 
mationen liber Datenobjekt -Typen 500 und Relations -Typen 600 
in verschiedenen Dateien und/oder Tabellen einer relationalen 
Datenbank abgespeichert . Jeder Typ wird als eine eigene XML- 
Entitat in einem eigenen Datensatz einer Tabelle abgespei- 
chert. Anwendungen 200 haben uber definierte Inf ormationswei- 
terleitungs-Schnittstellen 250 Lese- und Schreibzugrif f auf 
die zentrale Datenbank 100 des erf indungsgemaSen Systems 10 
als zentraler Datenhaltung . Vorzugsweise werden hierfur Stan- 
dards wie „Open Database Connectivity" (ODBC) zur Verbindung 
mit relationalen Datenbanken und die „ Standard Query Langua- 
ge" (SQL) als Standardsprache fur Abfragen von relationalen 
Datenbanken verwendet. Diese Ausf uhrungsf orm ermoglicht es, 
jede SQL- und ODBC-fahige relationale oder obj ektorientierte 
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Datenbank einzusetzen und bei Bedarf nachtraglich eine Daten- 
bank durch eine andere zu ersetzen, ohne erneut Daten einge- 
ben oder das zentrale Diensteprogramm 98 oder gar eine Anwen- 
dung 200 verandern zu mussen. 

Datenobjekte 3 00 werden vorzugsweise gemeinsam mit dem jewei- 
ligen Produktmodell 150 abgespeichert , Relationen hingegen 
getrennt von den Anwendungen 2 00 in der zentralen Datenbank 
100 gemeinsam mit den Typen. Die Benutzeroberf lache 50 des 
erf indungsgemaSen Systems 10 wird vorzugsweise getrennt vom 
zentralen Diensteprogramm 98 realisiert. Damit kann die Be- 
nutzeroberf lache 50 auf verschiedene Benutzer zugeschnitten 
und w personalisiert u werden, ohne die Datenhaltung an ver- 
schiedene Benutzergruppen anpassen zu mussen. Beispielsweise 
werden einem erfahrenen Benutzer mehr Handlungsmoglichkeiten 
angeboten als einem Neuling, ein Neuling erhalt hingegen mehr 
Hilf estellungen . 

Das zentrale Diensteprogramm 98 erzeugt und verwaltet daruber 
hinaus vorzugsweise Modelle fur die Lese- und Schreibberech- 
tigungen, das Verhalten, die Fahigkeiten und die Vorlieben 
von Benutzern, die mindestens eine der Anwendungen 2 00 benut- 
zen (user modeling) . Diese „Benutzer-Prof ile w (user profiles) 
werden in der zentralen Datenbank 100 verwaltet, Hierbei wer- 
den z. B. die Benutzer in verschiedene Klassen kategorisiert . 
Die Anwendungen 200 haben Lesezugriff auf diese Profile und 
erzeugen lokale Benutzeroberf lachen der Anwendungen, die auf 
den jeweiligen Benutzer zugeschnitten sind. Weil diese Profi- 
le und Berechtigungen fur die Benutzer zentral gespeichert 
und verwaltet werden, brauchen sie nur einmal erzeugt und ge- 
pflegt zu werden. Nicht erforderlich ist es, daS jede Anwen- 
dung 200 solche Profile separat verwaltet. Dies ist zwangs- 
laufig mit doppelter Datenhaltung und erheblich hoherem Auf- 
wand verbunden. 

Zu einem Benutzerprof il gehoren vorzugsweise auch Informatio- 
nen, die festlegen, wie die Datenobjekt- Typen dem jeweiligen 
Benutzer prasentiert werden. Neben Festlegungen zur Darstel- 
lungsform wird festgelegt, in welcher Reihenfolge welche Da- 
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tenobj ekt -Typen in einem Navigations-Baum auftreten, der dem 
Benutzer prasentiert wird. Dieser Navigations-Baum kann mit 
der Taxonomie ubereinstimmen, aber auch anders aufgebaut sein 
und nicht alle abstrakten Datenobj ekt -Typen (Typen mit Unter- 
typen) zeigen, z. B. nur die instant iierbaren Datenobj ekt - 
Typen. Der Navigations-Baum fur einen bestimmten Benutzer 
wird so aufgebaut, daS der Benutzer bestimmte Datenobj ekt - 
Typen mit wenigen Operationen (z. B. „Ausklappen" und Auswah- 
len) erreicht. Datenobj ekt -Typen , die ein Benutzer haufig 
verwendet, erreicht er schneller als andere Datenobj ekt - 
Typen. 

Das erf indungsgemafie System 10 besitzt eine Benutzeroberf la- 
che 50, die vorzugsweise den Benutzern der Anwendungen 200 
verborgen ist und von einem Verwalter und Administrator der 
zentralen Datenbank 100 und des zentralen Diensteprogramms 98 
benutzt wird. 

Im folgenden werden die beiden Syntaxen fur zwei beispielhaf- 
te Datenmodelle skizziert. Das erste Datenmodell, im folgen- 
den Klassenmodell genannt, legt fest, wie Ressourcen- 
Kategorien, Ressourcen- Typen und Datenobj ekt -Typen in der 
zentralen Datenbank 100 abgespeichert werden. Das zweite Da- 
tenmodell, im folgenden Instanzenmodell genannt, legt fest, 
wie Ressourcen (-Instanzen) in der zentralen Datenbank 100 ab- 
gespeichert werden. Die Syntax des Instanzenmodells laSt sich 
auch zur Abspeicherung von Datenobj ekten verwenden. Die Fest- 
legungen fur beide Datenmodelle lassen sich z. B. mit Hilfe 
von XML und XSD realisieren. 

Die Syntax fur das Klassenmodell legt folgendes fest: 

• Auf oberster Ebene umfafit das Klassenmodell mindestens ei- 
ne Klasse, auSerdem bei Bedarf eine Festlegung, welche 
Version des Klassenmodells verwendet wird. Das Klassenmo- 
dell kann beliebig viele Klassen umfassen. 

• Fur eine Klasse werden folgende Inf ormationen f estgelegt : 

ob die Klasse eine Ressourcen-Kategorie, ein Ressourcen- 
Typ oder ein Datenobj ekt -Typ ist, 
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eine interne Kennung sowie mindestens einen nach auBen 
sichtbaren Namen der Klasse - vorzugsweise wird ein Name 
pro verwendete naturliche Sprache abgespeichert , 

- welche einfachen Parameter die Klasse besitzt, wobei ei- 
ne Klasse keinen, einen oder mehrere einfachen Parameter 
hat. Fur jeden Parameter werden eine interne Kennung und 
mindestens ein nach aufien sichtbarer Name, die Mefiein- 
heit (z. B. mm), ein elementarer Datentyp (z. B. ganze 
Zahl) , ein voreingestellter Wert (default value) , 
Zugrif f sinf ormationen, ein Wertebereich und Erlauterun- 
gen abgespeichert, 

welche komplexen Parameter die Klasse besitzt, wobei ei- 
ne Klasse keinen, einen oder mehrere komplexen Parameter 
hat . Ein komplexer Parameter verweist auf einen Typ kom- 
plexer Parameter, das ist ein benutzerdef inierter Daten- 
typ / und umfaSt interne Kennung, Namen und voreinge- 
stellte Werte, 

welche Methoden die Klasse besitzt, wobei eine Klasse 
keine, eine oder mehrere Methoden besitzt- Jede Methode 
ist durch interne Kennung, Namen, Liste der Argument e 
(mit Argument -Name und Datentyp) , Typ des Ruckgabewert 
(return type) und Methodenrumpf (body) gekennzeichnet , 

- welche Abhangigkeiten die Klasse besitzt, wobei die Ab- 
hangigkeiten als automatisch auswertbare Vorschriften 
formuliert werden, 

- Verwaltungs-Inf ormationen, z. B. Festlegungen, wer Lese- 
und wer Schreibzugrif f auf die Klasse hat, wer wann die 
Klasse angelegt hat, wer sie wann zuletzt verandert hat, 
welche Anwendungen 200 lesend auf die Klasse zugegriffen 
haben . 

Falls die Klasse ein Relations-Typ ist: ein Verweis auf 
die zugeordnete Relations -Typ- Kategorie 



^ — PCT7EP2003/006270 

WO 2004/003798 ^ 



43 



- Falls die Klasse ein Relations-Typ 1st: die dem Relati- 
ons -Typ zugeordneten Partner (Datenobj ekt-Typen und/oder 
andere Relations-Typen) 

. Externe Verweise auf UDF-Dateien, also Dateien mit be- 
nutzerdefinierten Konstruktions-Gestaltungselementen (u- 
ser-defined features) fur ein bestimmtes CAD-Werkzeug, 
abgespeichert in einem fur das Werkzeug spezifischen Da- 
tenf ormat . 

. Die Festlegungen uber die dem Relations-Typ zugeordneten 
Partner haben vorzugsweise folgende Struktur: 

Wie viele Partner sind Datenobj ekt-Typen, wie viele an- 
dere Relations-Typen? 

- die internen Kennungen der Partner, 

- die Richtung, in der jeder Partner an der Relation be- 
teiligt ist (z. B. Eingang, Ausgang oder richtungslos) , 

. die fremden Rollen, die die Partner bezuglich der Rela- 
tion spielen, 

- die eigenen Rollen, die die Relation bezuglich der Part- 
ner spielt, 

und die Mitgliedschaf ts-Intervalle (Kardinalitaten) der 
Partner . 

Eine automatisch auswertbare Vorschrift kann als Parameter o- 
der als Methode eines Relations-Typs oder einer Relations- 
Typ-Kategorie realisiert sein. 

Die Syntax fur das Instanzenmodell legt folgendes f est : 

• Auf oberster Ebene umfafit das Instanzenmodell mindestens 
eine Instanz, also eine Relation oder ein Datenobj ekt, au- 
Serdem bei Bedarf eine Festlegung, welche Version des In- 
stanzenmodells verwendet wird. Das Instanzenmodell kann 
beliebig viele Instanzen umfassen. 

• Fur eine Instanz werden folgende Inf ormationen f estgelegt : 

Ob die Instanz eine Relation oder ein Datenobj ekt ist, 
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einen Verweis auf den Relations-Typ bzw. Datenobj ekt- 
Typ, dem die Instanz angehort, und zwar vorzugsweise 
durch Angabe der internen Kennung des Typs, 

eine interne Kennung sowie mindestens einen nach auSen 
sichtbaren Namen der Instanz - vorzugsweise wird ein Na- 
me pro verwendete naturliche Sprache abge spei chert , 

- welche einfachen Parameter die Instanz besitzt, 
welche komplexen Parameter die Instanz besitzt, 

- Verwaltungs-Informationen, 

die Rollen, die die beteiligten Partner spielen, vor- 
zugsweise als Vektor mit einzelnen Rollen und Verweisen 
auf die Partner- Instanzen realisiert, und 

- die Mitgliedschaf ts-Intervalle fur die beteiligten Part- 
ner. 

Beispielsweise wird ein Datensatz pro Datenobj ekt-Typ 500 ge- 
maS dem Klassenmodell angelegt. Fur einen Relations-Typ 
600.1, der n andere Typen verbindet, werden n+1 Datensatze 
angelegt, namlich einen fur den Relations-Typ 600.1 selber 
und je einen fur einen Verweis auf einen Partner, d. h. einen 
Datenobj ekt-Typ 500. a oder auf einen anderen Relations-Typ 
600. a, der dem Relations-Typ 600.1 zugeordnet ist und durch 
600.1 mit anderen Typen verbunden wird. 

Vorzugsweise wird die relationale Datenbank in Normalform 
strukturiert , jede Tabelle realisiert 1:1- und l:n- 
Verknvipf ungen, aber keine m:n-Verknupf ungen mit m > 1 und 
n > 1. Die internen Kennungen der Typen fungieren als Schlus- 
sel der Datensatze. Die XML-Anweisungen zur Representation 
der Parameter und Methoden eines Typs werden als Text in eine 
einzige Zelle des Datensatzes eingetragen. Eine XML-Anweisung 
fur einen Verweis auf einen anderen Typ wird ebenfalls in ei- 
ne einzige Zelle eingetragen. Diese Ausf uhrungsf orm hat u. a. 
den Vorteil, daS Inf ormationen schnell aus der zentralen Da- 
tenbank 100 eingelesen werden konnen und daS das Datenbank- 
Schema auch bei Anderung eines Datenmodells, z. B. des mit- 
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tels "XML Schema Definition" (XSD) realisierten Klassenmo- 
dells, nicht geandert zu werden braucht . 

Beim Einlesen der Relations-Typ-Kategorien, Relations-Typen 
und Datenobjekt-Typen aus der zentralen Datenbank 100 werden 
die Verknupf ungen zwischen Kategorien und Typen in Form von 
doppelt verzeigerten Listen im Arbeitsspeicher (random access 
memory) der Datenverarbeitungsanlage verfugbar gehalten. Das 
zentrale Diensteprogramm 98 erzeugt diese Listen im Arbeits- 
speicher. Falls eine Anwendung 200 Inf ormationen uber eine 
Kategorie oder einen Typ benotigt, z. B. die Taxonomie unter 
Relations-Typ-Kategorien, so ist kein erneuter Lesezugriff 
auf die zentrale Datenbank 100 erf orderlich . Vielmehr wird 
die benotigte Information mit Hilfe von Verweisen (pointer) 
auf bestimmte Speicherzellen des Arbeitsspeichers beschafft. 
Diese Ausf uhrungsf orm spart Rechenzeit ein, weil Zugriffe auf 
permanente Speichermedien mehr Zeitbenotigen als solche auf 
ein temporares Speichermedium wie einen Arbeitsspeicher. 



Bezugszeichenliste 



Zeichen 


Bedeu tung 


10 


Erf indungsgemaSes System 


50 


Benutzeroberf lache des erf indungsgemaSen 
Systems 


60 


Inf erenzmaschine 


98 


Zentrales Diensteprogramm 


100 


Zentrale Datenbank 


110.1, 110.2, . . . 


Lokale Datenhaltungen der Anwendungen 


150.1, 150.2, . . . 


Produkt- oder Prozefimodelle der Anwendungen 


200.1, 200.2, . . . 


Anwendungen 


250.1, 250.2, . . . 


Inf ormationsweiterleitungs-Schnittstellen 


300.1, 300.2, . . . 


Datenobj ekte 
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400.1, 


400.2 


Relationen 


500.1, 


500 . 2 , ... 


Datenob j ekt -Typen 


600.1, 


600 . 2 , ... 


Re 1 at ions - Typen 
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Patent ans p ruche 



1. System (10) zur Erzeugung von Informationen uber Datenob- 
jekte, 

wobei ein Datenobjekt einen Bestandteil eines technischen 
Produkts Oder einen Schritt eines Entstehungsprozesses 
fur das Produkt reprasentiert, 

und das System (10) 

eine Einrichtung zur Erzeugung von Typen (500.1, 
500.2, ...) von Datenobjekt en (300.1, 300.2, -..) 

- und eine Einrichtung zur Erzeugung von automatisch 

auswertbaren Vorschrif ten, deren Auswertung typisierte 
Datenobjekte (300.1, 300.2, ...) in Abhangigkeit von 
anderen typisierten Datenobjekten (300.1, 300.2, ...) 
ermittelt, generiert und/oder verandert, 

umf a£t , 

dadurch gekennzeichnet, 

daS das System (10) zusatzlich 

eine Einrichtung zur Erzeugung von Typen (600.1, 
600.2, ...) von Relationen (400.1, 400.2, ...) zwi- 
schen Datenobjekten (3 00.1, 3 00.2, ...), 
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eine Einrichtung zur Zuordnung von Datenobjekt-Typen 
(500.1, 500.2, ...) zu einem Relations -Typ (600.1, 
600 . 2 , . . . ) , 

und eine Einrichtung zur Zuordnung von automat isch 
auswertbaren Vorschriften zu Relations-Typen (600.1, 
600 .2, . . . ) 

umf afet . 

2. System nach Anspruch 1, 

dadurch gekennzeichnet, 
daS das System (10) 

- eine Einrichtung zur Erzeugung von Kategorien von Re- 
lations-Typen (600.1, 600.2, ...) 

- und eine Einrichtung zur Erzeugung einer Taxonomie un- 
ter Relations -Typ-Kategorien 

umf afit 

und die Einrichtung zur Erzeugung von Relations-Typen so 
ausgestaltet ist, 

daS mit ihr ein Relations-Typ (600.1, 600.2, ...), der zu 
einer vorgegebenen Kategorie gehort, erzeugbar ist. 

3. System nach Anspruch 2, 

dadurch gekennzeichnet, 

daS das System (10) 

einen ersten Inf ormationsspeicher mit einer ersten an- 
wendungsubergreif enden erweiterbaren Standard- 
Bibliothek mit Datenobjekt-Typen (500.1, 500.2, 
...)und Relations-Typen (600.1, 600.2, ...), 

einen zweiten Inf ormationsspeicher mit einer zweiten 
anwendungsubergreif enden erweiterbaren Standard- 
Bibliothek mit Relations-Typ-Kategorien 
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und eine Einrichtung zur Erzeugung einer Relations- 
Typ-Kategorie als Unterkategorie einer Relations-Typ- 
Kategorie der zweiten Standard-Bibliothek 

umf a£t . 

4. System nach Anspruch 2 oder Anspruch 3, 

dadurch gekennzeichnet, 

daS das System (10) 

einen ersten Datenspeicher fur Relations-Typ- 
Kategorien, 

einen zweiten Datenspeicher fur Datenobj ekt-Typen 
(500.1, 500.2, . ..) und Relations -Typen (600.1, 600.2, 
. . .) 

und einen dritten Datenspeicher fur typisierte Relati- 
onen (400.1, 400.2, ...) 

umf aiSt . 

5. System nach Anspruch 4, 

dadurch gekennzeichnet, 

daS das System (10) eine relationale Datenbank fur die 
drei Datenspeicher umfaSt 

und ein Datensatz dieser Datenbank fur eine Relations- 
Typ-Kategorie, einen Datenobj ekt-Typ (500.1, 500.2, ...), 
einen Relations-Typ (600.1, 600.2, ...) oder eine Relati- 
on (400 . 1, 400 . 2 , . . . ) 

eine Zelle fur eine eindeutige Kennung und mindestens ei- 
ne Zelle fur Inf ormationen, die im Datenformat XML struk- 
turiert sind, umfaSt. 



6. System nach einem der Anspruche 1 bis 5, 

dadurch gekennzeichnet, 
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daS das System (10) eine Einrichtung zur Zuordnung eines 
Relations -Typs (600.1, 600.2, ...) zu einem anderen Rela- 
tions-Typ (600.1, 600.2, ...) umf a£t . 

7. System nach einem der Anspruche 1 bis 6, 

dadurch gekennzeichnet, 

dafi das System (10) eine Einrichtung zur Erzeugung einer 
Relation (400.1, 400.2, ...), die von einem vorgegebenen 
Relations-Typ (600.1, 600.2, ...) ist, umf afit . 

8. System (10) zur Erzeugung von Inf ormationen uber Datenob- 
jekte (300.1, 300.2, ...), 

wobei ein Datenobjekt (300.1, 300.2, ...) einen Bestand- 
teil eines technischen Produkts oder einen Schritt eines 
Entstehungsprozesses fur das Produkt reprasentiert , 

und das System (10) 

eine Einrichtung zur Erzeugung von Typen (500.1, 
500.2, ...) von Datenobjekten (300.1, 300.2, ...) 

und eine Einrichtung zur Erzeugung von automatisch 
auswertbaren Vorschrif ten, deren Auswertung typisierte 
Datenobjekte (300.1, 300.2, ...) in Abhangigkeit von 
anderen typisierten Datenobjekten (300.1, 300.2, ...) 
ermittelt, generiert und/oder verandert, 

umf aSt , 

dadurch gekennzeichnet, 

dafi das System (10) 

eine Einrichtung zur Zuordnung eines Datenobj ekt -Typs 
(500.1, 500.2, ...) zu mindestens einer von mindestens 
zwei verschiedenen Phasen des Entstehungsprozesses 

- und eine Einrichtung zur Erzeugung einer einzigen Ta- 
xonomie 
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- fur Datenobjekt-Typen (500.1, 500.2, . ..), die einer 
erst en Phase zugeordnet sind, 

- und fur Datenobjekt-Typen (500,1, 500.2, . ..), die 
einer zweiten Phase zugeordnet sind 

umf afit . 

9. System nach einem der Anspriiche 1 bis 8, 

dadurch gekennzeichnet, 

daS die Einrichtung zur Zuordnung von Datenobjekt-Typen 

die Zuordnung von jeweils mindestens zwei der folgenden 
Datenobjekt-Typen (500.1, 500.2, ...) zu einem Relations- 
Typ (600.1, 600.2, ...) ermoglicht: 

Typen von Konstruktions-Gestaltungselementen, 

Typen von Bauteilen, 

Typen von Zusammenbauten, 

Typen von Fertigungs-Gestaltungselementen, 

- Typen von Qualitats-Gestaltungselementen, 

- Typen von MeS-Gestaltungselementen, 

- Typen von Priif -Gestaltungselementen, 
Typen von Werkstoffen, 

Typen von Fertigungs-Vorrichtungen, 
Typen von Betriebsmitteln 

- und Typen von Kommentaren. 



10. System nach einem der Anspriiche 1 bis 9, 

dadurch gekennzeichnet, 

daS das System (10) eine Inf ormationsweiterleitungs- 
Schnittstelle (250.1, 250.2, ...) zu einer Datenverarbei- 
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tungseinrichtung zum Erzeugen und Bearbeiten eines Mo- 
dells (150.1, 150.2, . ..) 

- des Produkts oder eines Teils des Produkts, 

eines Herstellungsprozesses zur Fertigung des Produkts 
oder eines Teils des Herstellungsprozesses, 

- eines Arbeit sablaufs oder eines Teils eines Arbeitsab- 
laufs, 

oder der Kosten zur Herstellung des Produkts 
umf aiSt . 

11. System nach Anspruch 10, 

dadurch gekennzeichnet, 

dalS die Inf ormationsweiterleitungs-Schnittstelle (250.1, 
250.2, ...) so ausgestaltet ist, 

dafi uber diese der Typ, eine Kennung und bei Bedarf Me- 
thoden und/oder Attributwerte eines von der Datenverar- 
beitungseinrichtung zu erzeugenden Datenobjekts (300.1, 
300.2, ...) ubermittelt werden konnen. 

12. System nach Anspruch 10 oder Anspruch 11, 
dadurch gekennzeichnet, 
daS 

das System (10) eine Einrichtung zur Erzeugung eines Be- 
nutzerprof ils eines Benutzers umf a&t , 

wobei das Benutzerprof il mindestens eine der folgenden 
Festlegungen umf aSt : 

Lese- und Schreibberechtigungen des Benutzers, 

- Fahigkeiten des Benutzers beim Erzeugen und Bearbeiten 
von Datenobjekten (300.1, 300.2, ...), 
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- Vorlieben des Benutzers beim Erzeugen und Bearbeiten 
von Datenobjekten (300.1, 300.2, ...) 

und die Inf ormationsweiterleitungs-Schnittstelle (250.1, 
250.2, .--) so ausgestaltet ist, 

da£ Festlegungen des Benutzerprof ils uber die Schnitt- 
stelle (250.1, 250.2, ...) ubermittelt werden konnen. 

13. Informationsmodell fur Datenobjekte (300.1, 300.2, ...), 

die jeweils einen Bestandteil eines technischen Produkts 
oder einen Schritt eines Entstehungsprozesses fur das 
Produkt reprasent ieren , 

wobei das Informationsmodell 

- Typen (500.1, 500.2, ...) von Datenobjekten (300.1, 
300.2, . . . ) 

- und automat isch auswertbare Vorschrif ten, deren Aus- 
wertung Datenobjekte (300.1, 300.2, ...) in Abhangig- 
keit von anderen Datenobjekten (300.1, 300.2, ...) ge- 
neriert oder verandert, 

umf aSt , 

dadurch gekennzeichnet, 
da6 

- das Informationsmodell Typen (600.1, 600.2, ...) von 
Relationen (400.1, 400.2, ...) zwischen Datenobjekten 
(300.1, 300.2, ...) umfafit, 

- einem Relations -Typ (600.1, 600.2, ...) eine automa- 
tisch auswertbare Vorschrift zuordenbar ist 

- und einem Relations-Typ (600.1, 600.2, ...) 

- mindestens zwei Datenobjekt -Typen (500.1, 500.2, 
. - •) 

- oder mindestens ein Datenobjekt -Typ (500.1, 500.2, 
...) und mindestens ein anderer Relations-Typ 
(600.1, 600.2, . . .) 



WO 2004/003798 




PCT/EP2003/006270 



oder mindestens zwei andere Relations-Typen (600.1/ 
600 . 2 , . . . ) 

zugeordnet sind. 



14. Inf ormationsmodell nach Anspruch 13 , 

dadurch gekennzeichnet, 
daS das Inf ormationsmodell 

Kategorien von Relations-Typen (600.1, 60 0.2, ...) 

und eine Taxonomie unter Relations-Typ-Kategorien 
umf aSt 

und ein Relations-Typ (600.1, 600.2, ...) einer Relati- 
ons -Typ-Kategor ie zuordenbar ist. 



15. Inf ormationsmodell nach Anspruch 13 oder Anspruch 14, 

dadurch gekennzeichnet, 

daS mindestens einem Relations-Typ (600.1, 600.2, ...) 
Mitgliedschaf ts-Intervalle und/oder Rollen 

fur die Datenobjekte (300.1, 300.2, ...) und/oder Relati- 
onen (400.1, 400.2, . ..), die durch eine Relation des Re- 
lations-Typs (600.1, 600.2, ...) verbunden werden, zuge- 
ordnet sind. 



16. Inf ormationsmodell nach einem der Anspruche 13 bis 15, 

dadurch gekennzeichnet, 

daS das Inf ormationsmodell Phasen-Datenobjekte (300.1, 
300.2, ...), die jeweils eine Phase des Entstehungspro- 
zesses reprasentieren, umfafit 

und einem Datenobjekt-Typ (500.1, 500.2, ...) ein Phasen- 
Datenobjekt (300.1, 300.2, ...) zuordenbar ist. 
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17. Informationsmodell nach einem der Anspruche 13 bis 16, 

dadurch gekennzeichnet, 

daS das Informationsmodell ein Datenmodell fur die dauer- 
hafte Speicherung von Datenobjekt-Typen (500. 1, 500.2, 
...) und/oder Relations -Typen (600.1, 600.2, ...), die 
gemafi dem Informationsmodell strukturiert sind, umf a£t . 
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Category ° Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



P.R. WILSON, M.J. WOZNY, M.J. PRATT 
(EDS.): "Geometric Modeling for Product 
Realization" 

1992 , ELESEVIER SCIENCE PUBLISHERS , 
NORTH-HOLLAND XP009020870 
cited in the application 
"A Systematic Approach for 
Design-Manufacturing Feature Mapping", 
Jami J. Shah, Davis Hsiao, John Leonard, 
pp. 205-221 
page 205 -page 211 
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| X| Further documents are listed in the continuation of box C. 


Patent family members are listed In annex. 


8 Special categories of cited documents : 

•A' document defining the general state of the art which is not 
considered to be of particular relevance 

a E a earlier document but published on or after the international 
filing date 

■L" document which may throw ^oubts on priority clalm(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P - document published prior to the international filing date but 
later than the priority date claimed 


■T" later document published after the International filing date 
or priority date and not In conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

'X' document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

■Y" document of particular relevance; the claimed invention 

cannot be considered to involve an Inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

*&' document member of the same patent family 


Date of the actual completion of the international search 


Date of mailing of the international search report 


18 November 2003 


12/01/2004 


Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL-2280HVRijswi]k 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 


Authorized officer 

Hasubek, B 
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C(Contlnuation) DOCUMENTS CONSIDERED TO BE RELEVANT 



sidErei 



P^HP 03/06270 



Category ° Citation of document, with indlcation.where appropriate, of the relevant passages 



Relevant to claim No. 



DE K RAKER K J ET AL: "MULTIPLE-WAY 
FEATURE CONVERSION TO SUPPORT CONCURRENT 
ENGINEERING" 

PROCEEDINGS OF THE THIRD SYMPOSIUM ON 
SOLID MODELING AND APPLICATIONS. SALT LAKE 
CITY, MAY 17-19, 1995, PROCEEDINGS OF 
THE SYMPOSIUM ON SOLID MODELING AND 
APPLICATIONS, NEW YORK, ACM, US, 
vol. SYMP. 3, 17 May 1995 (1995-05-17), 
pages 105-114, XP000530111 
ISBN: 0-89791-672-7 

page 107, right-hand column -page 112, 
left-hand column 
figure 9 

KRUTH J-P ET AL: "Extracting process 
planning information from various wire 
frame and feature based CAD systems" 
COMPUTERS IN INDUSTRY, ELSEVIER SCIENCE 
PUBLISHERS. AMSTERDAM, NL, 
vol . 30, no. 2, 

30 September 1996 (1996-09-30), pages 
145-162, XP004013452 
ISSN: 0166-3615 

page 147, left-hand column, paragraph 2 
page 147, right-hand column, paragraph 2 
page 151 -page 157 
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Form PCTVISA/210 (continuation of second sheet) (July 1992) 
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INTERNATI 



am^. SEARCH REPORT I Mei^feil 



application No. 

706270 



Box I Observations where certain claims were found unsearchable (Continuation of item 1 of first sheet) 



This international searchreport has not been established inrespect of certain claims under Article 1 7(2)(a) for the following reasons : 
Claims Nos.: 13-17 



because they relate to subject matter not required to be searched by this Aumority, namely: 

See Supplemental Sheet 



2 . Q^j Claims Nos. : 

because they relate to parts of the international application that do not compiy with the prescribed requirements to such 
an extent that no meaningful international search can be carried out, specifically: 



3 . I I Claims Nos. : 

1 — ' because they are dependent claims and are not drafted in accordance with the second and third sentences of Rule 6. 4(a). 



Box H Observations where unity of invention is lacking (Continuation of item 2 of first sheet) 



This International Searching Authority found multiple inventions in this international application, as follows: 



1. |~| As all required additional search fees were timely paid by the applicant, this international search report covers all 

searchable claims. 

2. As aU searchable claims cou^^ 
of any additional fee. 

3 . f - ] As only some of the required additional search fees were timely paid by the applicant, this international search report 
1 — 1 covers only those claims for which fees were paid, specifically claims Nos. : 



4. I I No required additional search fees were timely paid by the applicant. Consequently, this international search report is 
1 — ' restricted to the invention first mentioned in the claims; it is covered by claims Nos.: 



Remark on Protest | | The additional search fees were accompanied by the applicant's protest. 

| | No protest accompanied the payment of additional search fees. 



Form PCTVISA/210 (continuation of first sheet (1)) (July 1992) 



INTERNATJ 



SEARCH REPORT 



EP02 




Continuation of LI 
Claims: 13-17 



In Claims 13-17 an "information model" is claimed. This represents an 
abstraction of a data structure, that is purely a presentation of information. 
Under PCT Rule 39.1(v) the subject matter of Claims 13-17 is thus a subject 
that is not searched (PCT Article 17(2)(a)(i)). 



FoimPCT/ISA/210 



INTERNATIONALES RECHERCHENBERICHT 



LERI 

m 

DUNGSC 



"fntemalj^^^ktenzeichen 

F^fcp 03/06270 



A. KLASSIRZJERUNG DES ANMELDUNGSGEGENSTANDES 

IPK 7 G05B19/418 G05B19/4097 606F17/50 



Nach der Intemallonalen Patentkiasslfikation (IPK) Oder nach der nallonalen Klassffikatlon und der IPK 



B. RECHERCHIERTE GEBIETE 



Recherchierter Mindestprutstoff (Klasslfikatlonssystem und Klassiflkationssymbole ) 

IPK 7 G05B G06F 



Recherchterte aber nicht zum MindestprGfstoff gehdrende VerdffentHchungen, sowelt dlese unter die recherchierten Gebiete faflen 



Wahrend der intemallonalen Recherche konsultierte elektronische Datenbank (Name der Datenbank und evtl. verwendete Suchbegriffe) 

EPO-Internal , WPI Data, PAJ 



C. ALS WESENTLICH ANGESEHENE UNTERLAGEN 



Kategorie 0 Bezetehnung der Verdffentlichung, soweit erforderiich unier Angabe der in Betracht kommenden TeBe 



Betr. Anspruch Nr. 



P.R. WILSON, M.J. WOZNY, M.J. PRATT 
(EDS.): "Geometric Modeling for Product 
Realization" 

1992 , ELESEVIER SCIENCE PUBLISHERS , 
NORTH-HOLLAND XP009020870 
in der Anmeldung erwahnt 
"A Systematic Approach for 
Design-Manufacturing Feature Mapping", 
Jami J. Shah, Davis Hsiao, John Leonard, 
pp. 205-221 
Seite 205 -Seite 211 



-/- 



1-12 



m 



Weftere VeroffentHchungen sind der Fortsetzung von FeJd C zu 
entnehmen 



□ 



Siehe Anhang Patentfamille 



6 Besondere Kategorien von angegebenen VeroffentHchungen 

•A" Verdffentlichung. die den altgemeinen Stand der Technik defmiert, 
aber nicht als besonders bedeutsam anzusehen 1st 

"E - Slteres Dokument, das jedoch erst am Oder nach dem intemallonalen 
Anmeldedatum veroffentllcht worden ist 

"L " Verdffentlichung, die geeignet ist, einen Prioritatsanspruch zweifeihaft er- 
scheinen zu lassen, oder durch die das Verdffentllchungsdatum einer 
anderen im Recherchenbericht genannten Verdffentlichung belegt werden 
soil oder die aus einem anderen besonderen Grund angegeben ist (wie 
ausgehlhrt) 

"O" Verdffentlichung, die slch auf eine mundliche Offenbarung, 

eine Benutzung, eine Ausstedung oder andere MaBnahmen bezieht 
•P" Verdffentlichung, die vor dem intemallonalen Anmeldedatum, aber nach 
dem beanspruchten Prioritatsdatum verdffentficht worden ist 



•T" Spatere Verdffentlichung, die nach dem inlemationalen Anmeldedatum 
oder dem Prioritatsdatum verdffentlicht worden 1st und mit der 
Anmeldung nicht kollldiert, sondem nur zum Verstandnis des der 
Erfindung zugrundeJiegenden Prinzips oder der ihr zugrundeliegenden 
Theorie angegeben 1st 

*X" Verdffentlichung von besonderer Bedeutung; die beanspruchte Erfindung 
kann attein aufgrund dieser Veroffentifchung nicht ais neu oder auf 
erflnderischerTatlgkeit beruhend betrachtet werden 

■Y' Verdffentlichung von besonderer Bedeutung; die beanspruchte Erfindung 
kann nicht als auf erRnderischer Tatlgkeit beruhend betrachtet 
werden, wenn die Verdffentlichung mlt einer oder mehreren anderen 
Verdffentlichungen dieser Kategorie in VerbJndung gebracht wird und 
diese Verbindung fur einen Fachmann naheliegend ist 

■&' Verdffentlichung, die Mitglied derselben PatentfamiHe Ist 



Datum des Abschlusses der intemallonalen Recherche 

18. November 2003 


Absendedatum des Internationalen Recherchenberichts i 

12/01/2004 


Name und Postanschrift der Internationalen Recherchenbehdrde 
EuropSfsches Patentamt, P.B. 5818 Patentlaan 2 
NL-2280HVR1jswijk 
TeL (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax (+31-70)340-3016 


Bevollmachtfgter Bediensteter 

Hasubek, B 
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C.(Fortsetzung) ALS WESENTLICH ANGESEHENE UNTERLAGEN 



Kategorie" Bezelchnung der VeroffentHchung, sowelt erforderiich unter Angabe der in Betracht kommenden Telle 



Betr. Anspruch Nr. 



DE K RAKER K J ET AL: "MULTIPLE-WAY 
FEATURE CONVERSION TO SUPPORT CONCURRENT 
ENGINEERING" 

PROCEEDINGS OF THE THIRD SYMPOSIUM ON 
SOLID MODELING AND APPLICATIONS. SALT LAKE 
CITY, MAY 17-19, 1995, PROCEEDINGS OF 
THE SYMPOSIUM ON SOLID MODELING AND 
APPLICATIONS, NEW YORK, ACM, US, 
Bd. SYMP. 3, 17. Mai 1995 (1995-05-17), 
Seiten 105-114, XP000530111 
ISBN: 0-89791-672-7 

Seite 107, rechte Spalte -Seite 112, linke 
Spalte 
Abbi ldung 9 

KRUTH J-P ET AL: "Extracting process 
planning information from various wire 
frame and feature based CAD systems" 
COMPUTERS IN INDUSTRY, ELSEVIER SCIENCE 
PUBLISHERS. AMSTERDAM, NL, 
Bd. 30, Nr. 2, 

30. September 1996 (1996-09-30), Seiten 
145-162, XP004013452 
ISSN: 0166-3615 

Seite 147, linke Spalte, Absatz 2 
Seite 147, rechte Spalte, Absatz 2 
Seite 151 -Seite 157 
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Fotmttatt PCT/1SA/210 (Fortsetzung von Blart 2) (Jull 1992) 



Seite 2 von 2 



INTERNATI 



MRler recherchenbericht Ml 1 



fnationales Aktenzeichen 
PCT/EP 03/06270 



Feld I Bemerkungen zu den Anspruchen, die sich als nicht recherchierbar erwiesen haben (Fortsetzung von Punkl 2 auf Blatt 1) 



GemSB Artikel 17(2)a) wurde aus folgenden Grunden fQr bestimmte AnsprQche kein Recherchenbericht erstellfc 



1. JjT] AnsprQche Nr. 13-17 
well sie sich auf Gegenstande bezi< 



wen sle sich auf Gegenstande beziehen, zu deren Recherche die BehoYde nicht verpfiichtet ist, nZmlich 

siehe Zusatzblatt WEITERE ANGABEN PCT/ISA/210 



2. | | Anspruche Nr. 

weil sie sich auf Teile der internationalen Anmeldung beziehen, die den vorgeschriebenen Anforderungen so wenig entsprechen, 
dafc eine sinnvolJe internationale Recherche nicht durchgefQhrt werden kann, namlich 



3. | | Anspruche Nr. 

well es sich dabei um abhangige Anspruche handelt, die nicht entsprechend Satz 2 und 3 der Regel 6.4 a) abgefaBt sind. 



Feld II Bemerkungen bei mangelnder Einheitlichkeit der Erfindung (Fortsetzung von Punkt 3 auf Blatt 1) 



Die internationale Recherchenbehcrde hat festgestellt, dafB diese Internationale Anmeldung mehrere Erfindungen enthaMt: 



1 . ] I Da der Anmelder alie erforderlichen zusatzlichen RecherchengebQhren rechtzeitig entrlchtet hat, erstreckt sich dieser 
1 — 1 internationale Recherchenbericht auf alle recherchierbaren Anspruche. 

2 I I Da fQr alle recherchierbaren AnsprQche die Recherche ohne einen Arbeltsaufwand durchgefQhrt werden konnte, der eine 
J — l zusatzlfche RecherchengebQhr gerechtfertigt hatte, hat die Behorde nicht zur Zahiung einer sotehen Gebahr aufgefordert. 



3. Da der Anmelder nur einige der erforderlichen zusatzlichen RecherchengebQhren rechtzeitig entrichtet hat, erstreckt sich dieser 
1 — 1 internationale Recherchenbericht nur auf die AnsprQche, fur die GebQhren entrichtet worden sind, namlich auf die 
Anspruche Nr. 



| 1 Der Anmelder hat die erforderlichen zusatzlichen RecherchengebQhren nicht rechtzeitig entrichtet Der internationale Recher- 
chenbericht beschrSnkt sich daher auf die In den AnsprGchen zuerst erwahnte Erfindung; dlese ist in folgenden Anspruchen er- 
faBt: 



Bemerkungen hmsichtlich efnes Widerspruchs Die zusatzlichen GebQhren wurden vom Anmelder unter Widerspruch gezahlt 

Die Zahiung zusatzlicher RecherchengebQhren erfolgte ohne Widerspruch. 



Formblatt PCT/ISA/210 (Fortsetzung von Blatt 1 (1))(Juli 1998) 



v, 




Internationales AktenzeichenPCT£P 03 X)6270 

WEITERE ANGABEN PCT/iSA/ 210 

Fortsetzung von Feld 1.1 
Anspruche Nr. : 13-17 



In den Anspruchen 13-17 wird eln "Informationsmodell" beansprucht. Dabei 
handelt es sich urn eine Abstraktion einer Datenstruktur, also eine reine 
Darstellung von Informationen. Der Gegenstand der AnsprQche 13-17 ist 
somit nach Regel 39.1(v) PCT ein Gegenstand, der nach Artikel 17.2(a)(1) 
nicht recherchiert wird. 



